Sample XML Payloads for Events in the Account and Master Plan Instances Class
- Event 701: Account Created
- Event 702: Account Administrative Contact Modified
- Event 703: Account Authentication Data Modified
- Event 704: Account Status Changed
- Event 705: Account Status Queued for Change
- Event 706: Account Supplemental Field Value Added
- Event 707: Account Supplemental Field Value Modified
- Event 708: Account Supplemental Field Value Deleted
- Event 709: Account’s Parent Account Assignment Modified
- Event 710: Parent Account Had New Child Account Assigned
- Event 711: Parent Account Had Existing Child Account De-assigned
- Event 712: Account Comment Added
- Event 713: Account Notification Profile Modified
- Event 714: Account Credit Card Pending Expiration
- Event 715: Account New Form of Payment Added
- Event 716: Account Form of Payment Modified
- Event 717: Account Billing Contact Modified
- Event 718: Account Master Plan Instance Modified
- Event 719: Account Supplemental Plan Modified
- Event 720: Account Master Service Plan Queued for Assignment
- Event 721: Account Supplemental Service Plan Queued for Assignment
- Event 722: Account Master Service Plan Queued Assignment Removed
- Event 723: Account Supplemental Service Plan Queued Assignment Removed
- Event 724: Account Master Service Plan Assigned
- Event 725: Account Supplemental Service Plan Assigned
- Event 726: Account Master Plan Instance De-assigned
- Event 727: Account Supplemental Plan De-assigned
- Event 728: Account Master Plan Instance Queued for De-assignment
- Event 729: Account Supplemental Plan Queued for De-assignment
- Event 730: Account Master Plan Instance Queued for Modification
- Event 731: Account Supplemental Plan Queued for Modification
- Event 732: Account Service Plan Contract Pending Expiration
- Event 733: Account Service Plan Contract Expired
- Event 734: Account Master Plan Instance Status Modified
- Event 735: Account Supplemental Plan Status Modified
- Event 736: Account Statement Contact Modified
- Event 737: Account Billing Group Created
- Event 738: Account Billing Group Modified
- Event 739: Account Billing Group Disabled
- Event 740: Account Dunning Group Created
- Event 741: Account Dunning Group Modified
- Event 742: Account Dunning Group Disabled
- Event 743: Account Master Plan Instance Dunning State Changed
- Event 744: Account Master Plan Instance Dunning Degrade Date Changed
- Event 745: Account Dunning Group Default Dunning Process Changed
- Event 746: Account First Billable Supplemental Service Plan Assigned Under Non-Billable Master Plan Instance
- Event 747: Account Free Master Plan Instance Replaced with Non-Free Master Plan Instance
- Event 748: Account Fulfillment Based Service Plan Assignment
- Event 749: Account Service Plan Unit Queued for Fulfillment
- Event 750: Account Service Plan Unit Fulfillment Complete
- Event 751: Account Contract Created
- Event 752: Account Contract Edited
- Event 753: Account Contract Deleted
- Event 754: Account Master Plan Instance Product Field Modified
- Event 755: Account Supplemental Plan Product Field Modified
- Event 756: Account Master Plan Unit Instance Product Field Modified
- Event 757: Account Supplemental Plan Unit Instance Product Field Modified
- Event 758: Account Master Plan Instance Porting Successful
- Event 759: Account Master Plan Instance Porting Failed
- Event 760: Account Installment Created
- Event 761: Account Installment Status Changed
- Event 762: Account Payment Plan Created
- Event 763: Account Payment Plan Status Changed
- Event 765: Coupon Assigned
- Event 766: Coupon Cancelled
- Event 767: Coupon Expired
- Event 801: Order Entered, Not Processed
- Event 802: Order Marked Eligible for Billing
- General Notes for System Integrators
This document provides a sample XML payload for each event in the Accounts and Master Plan Instances class. Use these samples as a reference when configuring your event notification receiver or when validating your integration against the Version 4.0 XSD schema. For a complete list of events and their descriptions, see Events in the Accounts and Master Plan Instances Class. For field definitions, see Accounts and Master Plan Instances Event Fields.
Note: Always validate the <auth_key> value in each incoming payload against the authentication key configured in your Aria account before processing any event. Discard any payload that presents an unrecognized or mismatched key.
Event 701: Account Created
Aria sends this notification when a new account is created in the billing system.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000001</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<status_cd>1</status_cd>
<currency>USD</currency>
<test_acct>N</test_acct>
<acct_contact>
<first_name>Jane</first_name>
<last_name>Smith</last_name>
<email>jane.smith@example.com</email>
<address1>123 Main Street</address1>
<city>San Francisco</city>
<state_prov>CA</state_prov>
<postal_code>94105</postal_code>
<country>US</country>
<phone>415-555-0100</phone>
</acct_contact>
<event_data>
<event_no>701</event_no>
<event_label>Account Created</event_label>
</event_data>
</apf2doc>
Note: When you receive this event, provision the account in your downstream systems using the acct_no as the immutable Aria identifier and client_acct_id as your own reference. Validate the currency field before creating billing records; a mismatch with your system default requires manual correction.
Event 702: Account Administrative Contact Modified
Aria sends this notification when the administrative contact information on an account is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000008</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<acct_contact>
<first_name>Jane</first_name>
<last_name>Smith-Johnson</last_name>
<email>jane.johnson@example.com</email>
<address1>456 Market Street</address1>
<city>San Francisco</city>
<state_prov>CA</state_prov>
<postal_code>94103</postal_code>
<country>US</country>
<phone>415-555-0200</phone>
</acct_contact>
<event_data>
<event_no>702</event_no>
<event_label>Account Administrative Contact Modified</event_label>
</event_data>
</apf2doc>
Note: Update the administrative contact record in your CRM or provisioning system with the new values from this payload. If your system caches the account’s email address for notifications, invalidate and refresh that cache immediately on receipt of this event.
Event 703: Account Authentication Data Modified
Aria sends this notification when the authentication credentials (user ID or password) on an account are modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000015</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<userid>jsmith_updated</userid>
<pin>****</pin>
<event_data>
<event_no>703</event_no>
<event_label>Account Authentication Data Modified</event_label>
</event_data>
</apf2doc>
Note: If your system mirrors Aria account credentials for single sign-on or API access, update those records on receipt of this event. Do not log or store the pin value; discard it after processing.
Event 704: Account Status Changed
Aria sends this notification when the status of an account changes.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000022</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<status_cd>41</status_cd>
<status_date>2026-06-15</status_date>
<event_data>
<event_no>704</event_no>
<event_label>Account Status Changed</event_label>
</event_data>
</apf2doc>
Note: The status_cd field carries the new account status. Common values include 1 (Active) and 41 (Cancelled). Use this event to gate access to your services; for example, revoke access when you receive a cancellation status code. Subscribe to event 705 to be notified before a queued status change takes effect.
Event 705: Account Status Queued for Change
Aria sends this notification when a future account status change is queued.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000029</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<queued_status_cd>41</queued_status_cd>
<queued_status_change_date>2026-07-01</queued_status_change_date>
<event_data>
<event_no>705</event_no>
<event_label>Account Status Queued for Change</event_label>
</event_data>
</apf2doc>
Note: Use queued_status_change_date to schedule downstream actions. Do not revoke access until the actual status change fires event 704. This event allows you to prepare your system for the upcoming transition without acting prematurely.
Event 706: Account Supplemental Field Value Added
Aria sends this notification when a new supplemental field value is added to an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000036</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<field_name>PREFERRED_CONTACT_METHOD</field_name>
<field_value>EMAIL</field_value>
<event_data>
<event_no>706</event_no>
<event_label>Account Supplemental Field Value Added</event_label>
</event_data>
</apf2doc>
Note: The field_name and field_value fields identify the new supplemental attribute. Synchronize this value to any downstream system that relies on account-level custom attributes. Check that the field name matches your integration’s expected schema before persisting the value.
Event 707: Account Supplemental Field Value Modified
Aria sends this notification when an existing supplemental field value on an account is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000043</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<field_name>PREFERRED_CONTACT_METHOD</field_name>
<field_value>PHONE</field_value>
<event_data>
<event_no>707</event_no>
<event_label>Account Supplemental Field Value Modified</event_label>
</event_data>
</apf2doc>
Note: The payload contains only the modified field. Locate the existing record by acct_no and field_name, then overwrite the stored value. If your system version-tracks supplemental fields, archive the previous value before applying the update.
Event 708: Account Supplemental Field Value Deleted
Aria sends this notification when a supplemental field value is deleted from an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000050</transaction_id>
<action>D</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<field_name>PREFERRED_CONTACT_METHOD</field_name>
<event_data>
<event_no>708</event_no>
<event_label>Account Supplemental Field Value Deleted</event_label>
</event_data>
</apf2doc>
Note: Remove the supplemental field identified by field_name from your downstream records for this account. If the field is required by your system, substitute a default value rather than leaving the record in an invalid state.
Event 709: Account’s Parent Account Assignment Modified
Aria sends this notification when the parent account assignment for a child account is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000057</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<senior_acct_no>11000001</senior_acct_no>
<event_data>
<event_no>709</event_no>
<event_label>Account's Parent Account Assignment Modified</event_label>
</event_data>
</apf2doc>
Note: Update your account hierarchy in downstream systems to reflect the new parent-child relationship. If your system applies billing roll-ups or reporting by parent account, recalculate those aggregates after updating the hierarchy.
Event 710: Parent Account Had New Child Account Assigned
Aria sends this notification to the parent account when a new child account is assigned to it.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000064</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<senior_acct_no>11000001</senior_acct_no>
<event_data>
<event_no>710</event_no>
<event_label>Parent Account Had New Child Account Assigned</event_label>
</event_data>
</apf2doc>
Note: This event fires on the parent account record. The acct_no in this payload is the parent account; the new child account fires event 709 with its own acct_no. Use both events together to maintain a consistent hierarchy in your system.
Event 711: Parent Account Had Existing Child Account De-assigned
Aria sends this notification to the parent account when an existing child account is removed from its hierarchy.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000071</transaction_id>
<action>D</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<senior_acct_no>11000001</senior_acct_no>
<event_data>
<event_no>711</event_no>
<event_label>Parent Account Had Existing Child Account De-assigned</event_label>
</event_data>
</apf2doc>
Note: Remove the de-assigned child from the parent’s hierarchy in your downstream systems. If your system applies credit limits or reporting quotas at the parent level, recalculate those values after processing this event.
Event 712: Account Comment Added
Aria sends this notification when a comment is added to an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000078</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<last_acct_comment>Customer requested billing cycle change to the first of the month.</last_acct_comment>
<event_data>
<event_no>712</event_no>
<event_label>Account Comment Added</event_label>
</event_data>
</apf2doc>
Note: Sync the comment text from last_acct_comment to your CRM or ticketing system if you mirror account notes across platforms. Note that last_acct_comment contains only the most recently added comment, not the full comment history.
Event 713: Account Notification Profile Modified
Aria sends this notification when the notification template group assignment on an account is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000085</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<notify_tmplt_group_id>TMPL-GROUP-002</notify_tmplt_group_id>
<notify_tmplt_group_label>Premium Customer Template Group</notify_tmplt_group_label>
<notify_tmplt_group_assign_lvl>1</notify_tmplt_group_assign_lvl>
<event_data>
<event_no>713</event_no>
<event_label>Account Notification Profile Modified</event_label>
</event_data>
</apf2doc>
Note: If your system tracks notification preferences independently, update those records to reflect the new template group. The notify_tmplt_group_assign_lvl field indicates the scope of the assignment (account-level or plan-instance-level).
Event 714: Account Credit Card Pending Expiration
Aria sends this notification when a credit card on file is approaching its expiration date.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000092</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<payment_method_no>30001</payment_method_no>
<client_payment_method_id>PM-VISA-001</client_payment_method_id>
<pay_method>1</pay_method>
<cc_suffix>4242</cc_suffix>
<cc_exp_mm>08</cc_exp_mm>
<cc_exp_yyyy>2026</cc_exp_yyyy>
<event_data>
<event_no>714</event_no>
<event_label>Account Credit Card Pending Expiration</event_label>
</event_data>
</apf2doc>
Note: Use the cc_exp_mm and cc_exp_yyyy fields to display a payment update reminder in your customer portal. The cc_suffix (last four digits) lets you identify the card to your customer without exposing the full card number. Trigger a proactive outreach workflow if the customer has not updated their payment method within a defined window before expiration.
Event 715: Account New Form of Payment Added
Aria sends this notification when a new payment method is added to an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000099</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<payment_method_no>30002</payment_method_no>
<client_payment_method_id>PM-AMEX-001</client_payment_method_id>
<pay_method>1</pay_method>
<cc_suffix>1001</cc_suffix>
<cc_exp_mm>12</cc_exp_mm>
<cc_exp_yyyy>2028</cc_exp_yyyy>
<event_data>
<event_no>715</event_no>
<event_label>Account New Form of Payment Added</event_label>
</event_data>
</apf2doc>
Note: Record the new payment method identifier (payment_method_no and client_payment_method_id) in your system. If your integration allows customers to switch their default payment method from a self-service portal, refresh the available payment method list after processing this event.
Event 716: Account Form of Payment Modified
Aria sends this notification when an existing payment method on an account is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000106</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<payment_method_no>30001</payment_method_no>
<client_payment_method_id>PM-VISA-001</client_payment_method_id>
<pay_method>1</pay_method>
<cc_suffix>4242</cc_suffix>
<cc_exp_mm>11</cc_exp_mm>
<cc_exp_yyyy>2027</cc_exp_yyyy>
<event_data>
<event_no>716</event_no>
<event_label>Account Form of Payment Modified</event_label>
</event_data>
</apf2doc>
Note: Invalidate any cached payment method details for this account and refresh from the updated payload values. If your system stores the card expiration date for pre-validation, update it with the new cc_exp_mm and cc_exp_yyyy values.
Event 717: Account Billing Contact Modified
Aria sends this notification when the billing contact information on an account is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000113</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<billing_contact>
<first_name>Robert</first_name>
<last_name>Jones</last_name>
<email>billing@example.com</email>
<address1>789 Mission Street</address1>
<city>San Francisco</city>
<state_prov>CA</state_prov>
<postal_code>94103</postal_code>
<country>US</country>
<phone>415-555-0300</phone>
</billing_contact>
<event_data>
<event_no>717</event_no>
<event_label>Account Billing Contact Modified</event_label>
</event_data>
</apf2doc>
Note: Update the billing contact record in your ERP or accounts-receivable system. If your system sends invoices directly, update the billing email address from the email field within billing_contact to ensure future invoices reach the correct recipient.
Event 718: Account Master Plan Instance Modified
Aria sends this notification when a master plan instance on an account is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000120</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<client_master_plan_instance_id>MPI-STANDARD-001</client_master_plan_instance_id>
<plan_no>50001</plan_no>
<plan_name>Standard Plan</plan_name>
<plan_units>1</plan_units>
<bill_day>1</bill_day>
<next_bill_date>2026-07-01</next_bill_date>
<event_data>
<event_no>718</event_no>
<event_label>Account Master Plan Instance Modified</event_label>
</event_data>
</apf2doc>
Note: The master_plan_instance_no is the immutable Aria-assigned identifier for this MPI. Use it as the primary key when updating subscription records in your downstream system. The client_master_plan_instance_id is the client-defined identifier and may change; always correlate records using master_plan_instance_no.
Event 719: Account Supplemental Plan Modified
Aria sends this notification when a supplemental plan instance on an account is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000127</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_instance_no>60001</plan_instance_no>
<client_plan_instance_id>SPI-ADDON-001</client_plan_instance_id>
<plan_no>55001</plan_no>
<plan_name>Add-On Service</plan_name>
<plan_units>2</plan_units>
<event_data>
<event_no>719</event_no>
<event_label>Account Supplemental Plan Modified</event_label>
</event_data>
</apf2doc>
Note: The plan_instance_no identifies the supplemental plan instance that was modified. Always process supplemental plan events in the context of the parent master_plan_instance_no to maintain correct plan hierarchy in your system.
Event 720: Account Master Service Plan Queued for Assignment
Aria sends this notification when a master service plan is queued for future assignment to an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000134</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<plan_no>50005</plan_no>
<plan_name>Enterprise Plan</plan_name>
<plan_queue_type>1</plan_queue_type>
<queued_status_cd>1</queued_status_cd>
<queued_status_change_date>2026-07-01</queued_status_change_date>
<event_data>
<event_no>720</event_no>
<event_label>Account Master Service Plan Queued for Assignment</event_label>
</event_data>
</apf2doc>
Note: Do not provision the new plan until the queued assignment fires event 724. Use the queued_status_change_date to anticipate the transition and prepare any downstream systems for the upcoming change. If the queued assignment is subsequently removed, event 722 will fire.
Event 721: Account Supplemental Service Plan Queued for Assignment
Aria sends this notification when a supplemental service plan is queued for future assignment to an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000141</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_no>55005</plan_no>
<plan_name>Premium Add-On</plan_name>
<plan_queue_type>1</plan_queue_type>
<queued_status_change_date>2026-07-01</queued_status_change_date>
<event_data>
<event_no>721</event_no>
<event_label>Account Supplemental Service Plan Queued for Assignment</event_label>
</event_data>
</apf2doc>
Note: Do not provision the supplemental plan until event 725 fires to confirm the assignment. Pair this event with event 723 to handle the case where a queued supplemental plan assignment is later removed before it takes effect.
Event 722: Account Master Service Plan Queued Assignment Removed
Aria sends this notification when a queued master service plan assignment is removed before it takes effect.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000148</transaction_id>
<action>D</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<plan_no>50005</plan_no>
<plan_name>Enterprise Plan</plan_name>
<event_data>
<event_no>722</event_no>
<event_label>Account Master Service Plan Queued Assignment Removed</event_label>
</event_data>
</apf2doc>
Note: Cancel any downstream preparation you initiated in response to event 720 for this plan. Remove the pending plan record from your system to prevent provisioning a plan that will no longer be assigned.
Event 723: Account Supplemental Service Plan Queued Assignment Removed
Aria sends this notification when a queued supplemental service plan assignment is removed before it takes effect.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000155</transaction_id>
<action>D</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_no>55005</plan_no>
<plan_name>Premium Add-On</plan_name>
<event_data>
<event_no>723</event_no>
<event_label>Account Supplemental Service Plan Queued Assignment Removed</event_label>
</event_data>
</apf2doc>
Note: Cancel any downstream preparation you initiated in response to event 721 for this supplemental plan. The plan will not be assigned to the account, and no provisioning action is required.
Event 724: Account Master Service Plan Assigned
Aria sends this notification when a master service plan is assigned to an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000162</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98770</master_plan_instance_no>
<client_master_plan_instance_id>MPI-ENT-001</client_master_plan_instance_id>
<plan_no>50005</plan_no>
<plan_name>Enterprise Plan</plan_name>
<plan_activation_date>2026-07-01</plan_activation_date>
<plan_date>2026-07-01</plan_date>
<next_bill_date>2026-08-01</next_bill_date>
<created_date>2026-07-01</created_date>
<event_data>
<event_no>724</event_no>
<event_label>Account Master Service Plan Assigned</event_label>
</event_data>
</apf2doc>
Note: Provision the new master plan instance in your downstream systems using master_plan_instance_no as the primary identifier. Use plan_activation_date to set the service start date. If this assignment follows a queued event (720), correlate the plan number to close out the pending record in your queue.
Event 725: Account Supplemental Service Plan Assigned
Aria sends this notification when a supplemental service plan is assigned to an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000169</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_instance_no>60005</plan_instance_no>
<client_plan_instance_id>SPI-PREM-001</client_plan_instance_id>
<plan_no>55005</plan_no>
<plan_name>Premium Add-On</plan_name>
<plan_activation_date>2026-07-01</plan_activation_date>
<plan_date>2026-07-01</plan_date>
<event_data>
<event_no>725</event_no>
<event_label>Account Supplemental Service Plan Assigned</event_label>
</event_data>
</apf2doc>
Note: Activate the supplemental service in your provisioning system under the parent master_plan_instance_no. Supplemental plans inherit billing from the master plan instance; do not create a separate billing record for the add-on unless your integration requires it.
Event 726: Account Master Plan Instance De-assigned
Aria sends this notification when a master plan instance is de-assigned from an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000176</transaction_id>
<action>D</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<client_master_plan_instance_id>MPI-STANDARD-001</client_master_plan_instance_id>
<plan_no>50001</plan_no>
<plan_name>Standard Plan</plan_name>
<plan_termination_date>2026-06-30</plan_termination_date>
<event_data>
<event_no>726</event_no>
<event_label>Account Master Plan Instance De-assigned</event_label>
</event_data>
</apf2doc>
Note: Deprovision the service associated with this master plan instance. Use plan_termination_date to set the end-of-service date. If the account retains other active master plan instances, do not close the account itself; only deactivate the services tied to this specific MPI.
Event 727: Account Supplemental Plan De-assigned
Aria sends this notification when a supplemental plan is de-assigned from an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000183</transaction_id>
<action>D</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_instance_no>60001</plan_instance_no>
<client_plan_instance_id>SPI-ADDON-001</client_plan_instance_id>
<plan_no>55001</plan_no>
<plan_name>Add-On Service</plan_name>
<plan_termination_date>2026-06-30</plan_termination_date>
<event_data>
<event_no>727</event_no>
<event_label>Account Supplemental Plan De-assigned</event_label>
</event_data>
</apf2doc>
Note: Remove the add-on service tied to plan_instance_no from your downstream system. If your system tracks feature entitlements by supplemental plan, revoke only those entitlements tied to this specific plan instance, not all add-ons on the account.
Event 728: Account Master Plan Instance Queued for De-assignment
Aria sends this notification when a master plan instance is queued for future de-assignment.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000190</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<client_master_plan_instance_id>MPI-STANDARD-001</client_master_plan_instance_id>
<queued_status_cd>41</queued_status_cd>
<queued_status_change_date>2026-07-31</queued_status_change_date>
<event_data>
<event_no>728</event_no>
<event_label>Account Master Plan Instance Queued for De-assignment</event_label>
</event_data>
</apf2doc>
Note: Do not deprovision the service until event 726 fires. Use queued_status_change_date to schedule any customer-facing messaging about the upcoming cancellation. If the queued de-assignment is reversed before the date, no deprovisioning is required.
Event 729: Account Supplemental Plan Queued for De-assignment
Aria sends this notification when a supplemental plan is queued for future de-assignment.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000197</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_instance_no>60001</plan_instance_no>
<queued_status_cd>41</queued_status_cd>
<queued_status_change_date>2026-07-31</queued_status_change_date>
<event_data>
<event_no>729</event_no>
<event_label>Account Supplemental Plan Queued for De-assignment</event_label>
</event_data>
</apf2doc>
Note: Do not remove the supplemental service until event 727 fires to confirm de-assignment. Notify your customer of the upcoming change using the queued_status_change_date if your integration manages customer lifecycle communications.
Event 730: Account Master Plan Instance Queued for Modification
Aria sends this notification when a master plan instance is queued for future modification.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000204</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<client_master_plan_instance_id>MPI-STANDARD-001</client_master_plan_instance_id>
<plan_no>50005</plan_no>
<plan_name>Enterprise Plan</plan_name>
<queued_status_change_date>2026-07-01</queued_status_change_date>
<event_data>
<event_no>730</event_no>
<event_label>Account Master Plan Instance Queued for Modification</event_label>
</event_data>
</apf2doc>
Note: Treat this as a pending-change notification. Do not apply the modification in your downstream system until event 718 fires to confirm the change took effect. Record the queued plan values so you can validate the subsequent modification event.
Event 731: Account Supplemental Plan Queued for Modification
Aria sends this notification when a supplemental plan instance is queued for future modification.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000211</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_instance_no>60001</plan_instance_no>
<plan_no>55005</plan_no>
<plan_name>Premium Add-On</plan_name>
<queued_status_change_date>2026-07-01</queued_status_change_date>
<event_data>
<event_no>731</event_no>
<event_label>Account Supplemental Plan Queued for Modification</event_label>
</event_data>
</apf2doc>
Note: Do not apply the supplemental plan change until event 719 fires to confirm the modification. Pair this event with event 719 to close the pending record in your queue when the change takes effect.
Event 732: Account Service Plan Contract Pending Expiration
Aria sends this notification when a service plan contract is approaching its expiration date.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000218</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<contract_no>20001</contract_no>
<contract_end_date>2026-09-15</contract_end_date>
<contract_type>1</contract_type>
<event_data>
<event_no>732</event_no>
<event_label>Account Service Plan Contract Pending Expiration</event_label>
</event_data>
</apf2doc>
Note: Use contract_end_date to trigger a renewal outreach workflow. This is an advance notice; the contract has not expired yet. Subscribe to event 733 to confirm when the contract actually expires.
Event 733: Account Service Plan Contract Expired
Aria sends this notification when a service plan contract expires.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000225</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<contract_no>20001</contract_no>
<contract_end_date>2026-09-15</contract_end_date>
<contract_type>1</contract_type>
<event_data>
<event_no>733</event_no>
<event_label>Account Service Plan Contract Expired</event_label>
</event_data>
</apf2doc>
Note: The contract has now expired. If your integration enforces contract-based feature entitlements, revoke them based on the contract identified by contract_no. If the plan continues after contract expiry (depending on the contract’s post-expiration action), do not deprovision the service until you receive a corresponding plan de-assignment event.
Event 734: Account Master Plan Instance Status Modified
Aria sends this notification when the status of a master plan instance is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000232</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<client_master_plan_instance_id>MPI-STANDARD-001</client_master_plan_instance_id>
<plan_no>50001</plan_no>
<plan_name>Standard Plan</plan_name>
<status_cd>2</status_cd>
<status_date>2026-06-15</status_date>
<event_data>
<event_no>734</event_no>
<event_label>Account Master Plan Instance Status Modified</event_label>
</event_data>
</apf2doc>
Note: The status_cd field carries the new MPI status. Common values include 1 (Active) and 2 (Suspended). Use this field to gate service access in your provisioning system; for example, restrict service when the MPI enters a suspended state.
Event 735: Account Supplemental Plan Status Modified
Aria sends this notification when the status of a supplemental plan instance is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000239</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_instance_no>60001</plan_instance_no>
<client_plan_instance_id>SPI-ADDON-001</client_plan_instance_id>
<plan_no>55001</plan_no>
<plan_name>Add-On Service</plan_name>
<status_cd>2</status_cd>
<status_date>2026-06-15</status_date>
<event_data>
<event_no>735</event_no>
<event_label>Account Supplemental Plan Status Modified</event_label>
</event_data>
</apf2doc>
Note: Apply the status change only to the add-on service tied to plan_instance_no. A status change on a supplemental plan does not affect the parent master plan instance; manage each plan’s service state independently.
Event 736: Account Statement Contact Modified
Aria sends this notification when the statement contact information on an account is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000246</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<statement_contact>
<first_name>Alice</first_name>
<last_name>Wong</last_name>
<email>statements@example.com</email>
<address1>321 Howard Street</address1>
<city>San Francisco</city>
<state_prov>CA</state_prov>
<postal_code>94105</postal_code>
<country>US</country>
<phone>415-555-0400</phone>
</statement_contact>
<event_data>
<event_no>736</event_no>
<event_label>Account Statement Contact Modified</event_label>
</event_data>
</apf2doc>
Note: Update the statement delivery address in your billing system or customer portal. If you send paper statements, update the mailing address from this payload. The statement contact is distinct from the administrative and billing contacts; update only the statement delivery record.
Event 737: Account Billing Group Created
Aria sends this notification when a new billing group is created on an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000253</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<billing_group_no>70001</billing_group_no>
<client_billing_group_id>BG-PRIMARY-001</client_billing_group_id>
<billing_group_name>Primary Billing Group</billing_group_name>
<primary_payment_method_no>30001</primary_payment_method_no>
<bill_day>1</bill_day>
<event_data>
<event_no>737</event_no>
<event_label>Account Billing Group Created</event_label>
</event_data>
</apf2doc>
Note: Create a corresponding billing group record in your system using billing_group_no as the Aria-assigned identifier. If your integration routes charges to different payment methods by billing group, associate the primary_payment_method_no with this group in your records.
Event 738: Account Billing Group Modified
Aria sends this notification when a billing group on an account is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000260</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<billing_group_no>70001</billing_group_no>
<client_billing_group_id>BG-PRIMARY-001</client_billing_group_id>
<billing_group_name>Primary Billing Group Updated</billing_group_name>
<primary_payment_method_no>30002</primary_payment_method_no>
<bill_day>15</bill_day>
<event_data>
<event_no>738</event_no>
<event_label>Account Billing Group Modified</event_label>
</event_data>
</apf2doc>
Note: Update the billing group record identified by billing_group_no. If the primary_payment_method_no changed, refresh the payment method association in your ERP or payment processing system.
Event 739: Account Billing Group Disabled
Aria sends this notification when a billing group on an account is disabled.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000267</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<billing_group_no>70001</billing_group_no>
<client_billing_group_id>BG-PRIMARY-001</client_billing_group_id>
<billing_group_name>Primary Billing Group</billing_group_name>
<event_data>
<event_no>739</event_no>
<event_label>Account Billing Group Disabled</event_label>
</event_data>
</apf2doc>
Note: Mark the billing group identified by billing_group_no as inactive in your system. If any master plan instances or supplemental plans were attached to this billing group, verify their new billing group assignment before processing the next billing cycle.
Event 740: Account Dunning Group Created
Aria sends this notification when a new dunning group is created on an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000274</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<dunning_group_no>80001</dunning_group_no>
<client_dunning_group_id>DG-STANDARD-001</client_dunning_group_id>
<dunning_group_name>Standard Dunning Group</dunning_group_name>
<event_data>
<event_no>740</event_no>
<event_label>Account Dunning Group Created</event_label>
</event_data>
</apf2doc>
Note: Create a dunning group record in your collections system if you manage dunning workflows externally. Use dunning_group_no as the primary identifier for this group in your integration.
Event 741: Account Dunning Group Modified
Aria sends this notification when a dunning group on an account is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000281</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<dunning_group_no>80001</dunning_group_no>
<client_dunning_group_id>DG-STANDARD-001</client_dunning_group_id>
<dunning_group_name>Standard Dunning Group Updated</dunning_group_name>
<event_data>
<event_no>741</event_no>
<event_label>Account Dunning Group Modified</event_label>
</event_data>
</apf2doc>
Note: Update the dunning group record in your system. If your integration maps dunning groups to specific retry schedules or escalation rules, verify that the updated group configuration still aligns with those rules.
Event 742: Account Dunning Group Disabled
Aria sends this notification when a dunning group on an account is disabled.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000288</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<dunning_group_no>80001</dunning_group_no>
<dunning_group_name>Standard Dunning Group</dunning_group_name>
<event_data>
<event_no>742</event_no>
<event_label>Account Dunning Group Disabled</event_label>
</event_data>
</apf2doc>
Note: Mark the dunning group identified by dunning_group_no as inactive. If any master plan instances were associated with this dunning group, check their dunning state after this event fires to confirm they have been reassigned.
Event 743: Account Master Plan Instance Dunning State Changed
Aria sends this notification when the dunning state of a master plan instance changes.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000295</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<dunning_group_no>80001</dunning_group_no>
<dunning_state>2</dunning_state>
<dunning_step>1</dunning_step>
<dunning_step_description>First Dunning Notice</dunning_step_description>
<next_dunning_date>2026-06-22</next_dunning_date>
<event_data>
<event_no>743</event_no>
<event_label>Account Master Plan Instance Dunning State Changed</event_label>
</event_data>
</apf2doc>
Note: Use the dunning_state and dunning_step fields to drive collections workflows in your CRM. The next_dunning_date field tells you when the next dunning action will fire. Do not downgrade service access based on dunning state alone; wait for an explicit status change event (event 734).
Event 744: Account Master Plan Instance Dunning Degrade Date Changed
Aria sends this notification when the dunning degrade date for a master plan instance changes.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000302</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<dunning_group_no>80001</dunning_group_no>
<next_dunning_date>2026-06-29</next_dunning_date>
<event_data>
<event_no>744</event_no>
<event_label>Account Master Plan Instance Dunning Degrade Date Changed</event_label>
</event_data>
</apf2doc>
Note: Update your collections system with the new degrade date. If you surface dunning timelines in a customer-facing portal, refresh the displayed date from next_dunning_date after receiving this event.
Event 745: Account Dunning Group Default Dunning Process Changed
Aria sends this notification when the default dunning process assigned to a dunning group changes.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000309</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<dunning_group_no>80001</dunning_group_no>
<dunning_group_name>Standard Dunning Group</dunning_group_name>
<event_data>
<event_no>745</event_no>
<event_label>Account Dunning Group Default Dunning Process Changed</event_label>
</event_data>
</apf2doc>
Note: If your integration mirrors dunning process configurations, refresh the dunning group’s process definition from Aria after processing this event. Master plan instances assigned to this dunning group will follow the new process on their next dunning cycle.
Event 746: Account First Billable Supplemental Service Plan Assigned Under Non-Billable Master Plan Instance
Aria sends this notification when the first billable supplemental service plan is assigned to an account under a non-billable master plan instance.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000316</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_instance_no>60010</plan_instance_no>
<plan_no>55010</plan_no>
<plan_name>Billable Add-On</plan_name>
<event_data>
<event_no>746</event_no>
<event_label>Account First Billable Supplemental Service Plan Assigned Under Non-Billable Master Plan Instance</event_label>
</event_data>
</apf2doc>
Note: This event fires when billing is introduced to an account that previously had only non-billable plans. Ensure your payment collection workflow activates for this account, and verify that a valid payment method is on file before the first billing cycle runs.
Event 747: Account Free Master Plan Instance Replaced with Non-Free Master Plan Instance
Aria sends this notification when a free master plan instance is replaced by a paid master plan instance.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000323</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98770</master_plan_instance_no>
<transistion_from_plan>50000</transistion_from_plan>
<transistion_to_plan>50001</transistion_to_plan>
<event_data>
<event_no>747</event_no>
<event_label>Account Free Master Plan Instance Replaced with Non-Free Master Plan Instance</event_label>
</event_data>
</apf2doc>
Note: Use transistion_from_plan and transistion_to_plan to update plan references in your CRM and provisioning system. Ensure that the account has a valid payment method on file, as billing will now commence for the paid plan.
Event 748: Account Fulfillment Based Service Plan Assignment
Aria sends this notification when a fulfillment-based service plan is assigned to an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000330</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_instance_no>60020</plan_instance_no>
<plan_no>55020</plan_no>
<plan_name>Fulfillment Plan</plan_name>
<fulfillment_status>1</fulfillment_status>
<event_data>
<event_no>748</event_no>
<event_label>Account Fulfillment Based Service Plan Assignment</event_label>
</event_data>
</apf2doc>
Note: Begin the fulfillment workflow in your provisioning system for the plan identified by plan_instance_no. Update the fulfillment status as fulfillment progresses, and subscribe to events 749 and 750 to track unit-level fulfillment milestones.
Event 749: Account Service Plan Unit Queued for Fulfillment
Aria sends this notification when a service plan unit is queued for fulfillment.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000337</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_unit_inst_no>70001</plan_unit_inst_no>
<plan_unit_inst_status>1</plan_unit_inst_status>
<event_data>
<event_no>749</event_no>
<event_label>Account Service Plan Unit Queued for Fulfillment</event_label>
</event_data>
</apf2doc>
Note: Queue the provisioning action in your fulfillment system for the plan unit instance identified by plan_unit_inst_no. Subscribe to event 750 to confirm when fulfillment completes.
Event 750: Account Service Plan Unit Fulfillment Complete
Aria sends this notification when fulfillment of a service plan unit is complete.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000344</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_unit_inst_no>70001</plan_unit_inst_no>
<plan_unit_inst_status>2</plan_unit_inst_status>
<fulfillment_date>2026-06-15</fulfillment_date>
<event_data>
<event_no>750</event_no>
<event_label>Account Service Plan Unit Fulfillment Complete</event_label>
</event_data>
</apf2doc>
Note: Mark the fulfillment record identified by plan_unit_inst_no as complete in your provisioning system and record the fulfillment_date. If your integration gates billing for this unit on fulfillment completion, trigger the billing confirmation workflow after processing this event.
Event 751: Account Contract Created
Aria sends this notification when a new contract is created for an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000351</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<contract_no>20005</contract_no>
<contract_type>1</contract_type>
<contract_start_date>2026-07-01</contract_start_date>
<contract_end_date>2027-06-30</contract_end_date>
<contract_duration_length>12</contract_duration_length>
<contract_duration_type>2</contract_duration_type>
<event_data>
<event_no>751</event_no>
<event_label>Account Contract Created</event_label>
</event_data>
</apf2doc>
Note: Record the contract in your CRM or ERP using contract_no as the primary identifier. Store both contract_start_date and contract_end_date so you can trigger renewal outreach workflows ahead of the contract end. Subscribe to event 732 for advance expiration notice.
Event 752: Account Contract Edited
Aria sends this notification when an existing contract on an account is edited.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000358</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<contract_no>20005</contract_no>
<contract_type>1</contract_type>
<contract_end_date>2027-09-30</contract_end_date>
<contract_renewal_duration_length>12</contract_renewal_duration_length>
<contract_renewal_duration_type>2</contract_renewal_duration_type>
<contract_renewal_end_date>2028-09-30</contract_renewal_end_date>
<event_data>
<event_no>752</event_no>
<event_label>Account Contract Edited</event_label>
</event_data>
</apf2doc>
Note: Update the contract record identified by contract_no with the revised terms. If your system tracks contract timelines for renewal reminders, refresh the calculated reminder date based on the updated contract_end_date.
Event 753: Account Contract Deleted
Aria sends this notification when a contract on an account is deleted.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000365</transaction_id>
<action>D</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<contract_no>20005</contract_no>
<event_data>
<event_no>753</event_no>
<event_label>Account Contract Deleted</event_label>
</event_data>
</apf2doc>
Note: Remove the contract record identified by contract_no from your downstream system. If your integration enforces contract-based feature entitlements or pricing, verify the account’s entitlement state after processing this deletion.
Event 754: Account Master Plan Instance Product Field Modified
Aria sends this notification when a product field on a master plan instance is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000372</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<client_master_plan_instance_id>MPI-STANDARD-001</client_master_plan_instance_id>
<field_name>PROVISIONING_STATUS</field_name>
<field_value>ACTIVE</field_value>
<event_data>
<event_no>754</event_no>
<event_label>Account Master Plan Instance Product Field Modified</event_label>
</event_data>
</apf2doc>
Note: Update the product field value in your provisioning or ERP system. The field_name identifies which attribute changed; map it to the corresponding attribute in your integration schema before applying the update.
Event 755: Account Supplemental Plan Product Field Modified
Aria sends this notification when a product field on a supplemental plan instance is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000379</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_instance_no>60001</plan_instance_no>
<field_name>DATA_QUOTA_GB</field_name>
<field_value>100</field_value>
<event_data>
<event_no>755</event_no>
<event_label>Account Supplemental Plan Product Field Modified</event_label>
</event_data>
</apf2doc>
Note: Apply the product field update to the supplemental plan instance identified by plan_instance_no. If your integration uses product fields to drive entitlements (such as data quotas), refresh the entitlement value in your provisioning system immediately after processing this event.
Event 756: Account Master Plan Unit Instance Product Field Modified
Aria sends this notification when a product field on a master plan unit instance is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000386</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_unit_inst_no>70001</plan_unit_inst_no>
<field_name>DEVICE_SERIAL</field_name>
<field_value>SN-ABC-123456</field_value>
<event_data>
<event_no>756</event_no>
<event_label>Account Master Plan Unit Instance Product Field Modified</event_label>
</event_data>
</apf2doc>
Note: Apply the product field update to the plan unit instance identified by plan_unit_inst_no. Unit-instance product fields typically carry device or subscriber-specific attributes; update the corresponding record in your provisioning database.
Event 757: Account Supplemental Plan Unit Instance Product Field Modified
Aria sends this notification when a product field on a supplemental plan unit instance is modified.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000393</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_unit_inst_no>70010</plan_unit_inst_no>
<field_name>FEATURE_FLAG</field_name>
<field_value>ENABLED</field_value>
<event_data>
<event_no>757</event_no>
<event_label>Account Supplemental Plan Unit Instance Product Field Modified</event_label>
</event_data>
</apf2doc>
Note: Apply the updated product field to the supplemental plan unit instance identified by plan_unit_inst_no. If the changed field controls a feature flag or capability in your downstream system, apply the change immediately to reflect the new entitlement state.
Event 758: Account Master Plan Instance Porting Successful
Aria sends this notification when a master plan instance porting operation succeeds.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000400</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98780</master_plan_instance_no>
<client_master_plan_instance_id>MPI-PORT-001</client_master_plan_instance_id>
<mpi_port_queue_id>PQ-20001</mpi_port_queue_id>
<source_acct_no>12345600</source_acct_no>
<source_master_plan_instance_no>98760</source_master_plan_instance_no>
<source_client_master_plan_instance_id>MPI-SRC-001</source_client_master_plan_instance_id>
<event_data>
<event_no>758</event_no>
<event_label>Account Master Plan Instance Porting Successful</event_label>
</event_data>
</apf2doc>
Note: Update your provisioning system to record the successful port. The source_acct_no and source_master_plan_instance_no identify the origin account and MPI from which the plan was ported. Close the porting queue record identified by mpi_port_queue_id after processing.
Event 759: Account Master Plan Instance Porting Failed
Aria sends this notification when a master plan instance porting operation fails.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000407</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98780</master_plan_instance_no>
<mpi_port_queue_id>PQ-20001</mpi_port_queue_id>
<event_data>
<event_no>759</event_no>
<event_label>Account Master Plan Instance Porting Failed</event_label>
</event_data>
</apf2doc>
Note: Investigate the porting failure and notify your operations team. The MPI identified by master_plan_instance_no remains on the source account; do not update the target account’s provisioning records. Review the porting queue record identified by mpi_port_queue_id for the failure reason.
Event 760: Account Installment Created
Aria sends this notification when a new installment is created for an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000414</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<installment_no>40001</installment_no>
<client_installment_term_id>INSTALL-TERM-001</client_installment_term_id>
<invoice_no>INV-90001</invoice_no>
<installment_status>1</installment_status>
<event_data>
<event_no>760</event_no>
<event_label>Account Installment Created</event_label>
</event_data>
</apf2doc>
Note: Record the installment in your ERP or accounts-receivable system using installment_no as the primary identifier. Link the installment to the invoice identified by invoice_no so your system can reconcile payments correctly.
Event 761: Account Installment Status Changed
Aria sends this notification when the status of an account installment changes.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000421</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<installment_no>40001</installment_no>
<installment_status>2</installment_status>
<status_change_date>2026-06-15</status_change_date>
<event_data>
<event_no>761</event_no>
<event_label>Account Installment Status Changed</event_label>
</event_data>
</apf2doc>
Note: Update the installment record identified by installment_no with the new status and status_change_date. If your system tracks installment payment schedules, adjust the outstanding balance calculation after processing each status change.
Event 762: Account Payment Plan Created
Aria sends this notification when a new payment plan is created for an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000428</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<payment_plan_no>50001</payment_plan_no>
<client_payment_plan_id>PP-MONTHLY-001</client_payment_plan_id>
<payment_plan_status>1</payment_plan_status>
<payment_plan_interval>1</payment_plan_interval>
<payment_plan_period_type>2</payment_plan_period_type>
<payment_plan_length>12</payment_plan_length>
<recurring_payment_amount>99.00</recurring_payment_amount>
<first_payment_plan_due_date>2026-07-01</first_payment_plan_due_date>
<payment_plan_bg_no>70001</payment_plan_bg_no>
<event_data>
<event_no>762</event_no>
<event_label>Account Payment Plan Created</event_label>
</event_data>
</apf2doc>
Note: Record the payment plan in your billing system using payment_plan_no as the primary identifier. Use first_payment_plan_due_date and recurring_payment_amount to initialize the payment schedule in your system. Validate that the billing group identified by payment_plan_bg_no has a valid primary payment method before the first due date.
Event 763: Account Payment Plan Status Changed
Aria sends this notification when the status of a payment plan changes.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000435</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<payment_plan_no>50001</payment_plan_no>
<client_payment_plan_id>PP-MONTHLY-001</client_payment_plan_id>
<payment_plan_status>3</payment_plan_status>
<payment_plan_status_change_date>2026-06-15</payment_plan_status_change_date>
<event_data>
<event_no>763</event_no>
<event_label>Account Payment Plan Status Changed</event_label>
</event_data>
</apf2doc>
Note: Update the payment plan record identified by payment_plan_no with the new status. A terminal status (such as completed or cancelled) should close the payment schedule in your billing system. Use payment_plan_status_change_date to record when the status transition occurred.
Event 765: Coupon Assigned
Aria sends this notification when a coupon is assigned to an account.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000442</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<coupon_cd>SUMMER2026</coupon_cd>
<coupon_assignment_no>90001</coupon_assignment_no>
<coupon_assignment_level>1</coupon_assignment_level>
<promo_cd>PROMO-SUMMER</promo_cd>
<event_data>
<event_no>765</event_no>
<event_label>Coupon Assigned</event_label>
</event_data>
</apf2doc>
Note: Record the coupon assignment in your CRM or loyalty system using coupon_assignment_no as the unique identifier. If your integration applies discounts at the time of coupon assignment rather than at billing, apply the discount immediately after processing this event.
Event 766: Coupon Cancelled
Aria sends this notification when a coupon assignment on an account is cancelled.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000449</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<coupon_cd>SUMMER2026</coupon_cd>
<coupon_assignment_no>90001</coupon_assignment_no>
<event_data>
<event_no>766</event_no>
<event_label>Coupon Cancelled</event_label>
</event_data>
</apf2doc>
Note: Remove the discount associated with coupon_assignment_no from your downstream records. If your system pre-applied a discount in response to event 765, reverse that discount to restore the standard price.
Event 767: Coupon Expired
Aria sends this notification when a coupon on an account expires.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000456</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<coupon_cd>SUMMER2026</coupon_cd>
<coupon_assignment_no>90001</coupon_assignment_no>
<event_data>
<event_no>767</event_no>
<event_label>Coupon Expired</event_label>
</event_data>
</apf2doc>
Note: Mark the coupon assignment identified by coupon_assignment_no as expired in your system. Depending on your billing model, coupon expiration may affect the account’s next invoice; verify that your billing integration reflects the post-expiration price at the next billing cycle.
Event 801: Order Entered, Not Processed
Aria sends this notification when an order is entered into the system but has not yet been processed.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000463</transaction_id>
<action>A</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_no>50001</plan_no>
<plan_name>Standard Plan</plan_name>
<event_data>
<event_no>801</event_no>
<event_label>Order Entered, Not Processed</event_label>
</event_data>
</apf2doc>
Note: Use this event to create a pending order record in your order management system. Do not fulfill the order until event 802 fires to confirm the order is eligible for billing. The order may be modified or cancelled before it is marked eligible.
Event 802: Order Marked Eligible for Billing
Aria sends this notification when an order is marked as eligible for billing.
<?xml version="1.0" encoding="UTF-8"?>
<apf2doc>
<request>
<version>4.0</version>
<sender>A</sender>
<transaction_id>100000470</transaction_id>
<action>M</action>
<class>A</class>
<auth_key>CLIENTAUTH12345</auth_key>
</request>
<client_no>10001</client_no>
<acct_no>12345678</acct_no>
<client_acct_id>CLIENT-ACCT-001</client_acct_id>
<userid>jsmith</userid>
<master_plan_instance_no>98765</master_plan_instance_no>
<plan_no>50001</plan_no>
<plan_name>Standard Plan</plan_name>
<event_data>
<event_no>802</event_no>
<event_label>Order Marked Eligible for Billing</event_label>
</event_data>
</apf2doc>
Note: Advance the order record to an “approved for billing” state in your order management system. This event confirms that Aria will include the order in the next billing run. If your integration fulfills services only after billing eligibility is confirmed, trigger the fulfillment workflow after processing this event.
General Notes for System Integrators
All payloads in the Accounts and Master Plan Instances class conform to the Version 4.0 schema. The <version> element inside the <request> block is fixed at 4.0 for all events in this schema version. Use this value to route payloads to the correct version of your payload parser when you run multiple schema versions in parallel.
The <sender> element is always A for outbound notifications from Aria to your system. Aria does not currently support inbound provisioning events from clients, so you will not encounter the value C in payloads received from Aria.
The <action> field in the <request> block indicates the type of change that triggered the event. A value of A indicates a creation or addition event. A value of M indicates a modification event, including status changes, queued changes, and updates to contact or plan data. A value of D indicates a deletion or de-assignment event. Use this field as the primary signal for routing logic in your integration layer.
The <acct_no> field is the immutable Aria-assigned account identifier. It does not change over the life of the account. The <client_acct_id> is the client-defined account identifier and may be updated by the client at any time. Always use <acct_no> as the primary key when correlating payloads to records in your downstream system. Similarly, <master_plan_instance_no> is the immutable MPI identifier, and <client_master_plan_instance_id> is the mutable client-defined equivalent. For supplemental plan instances, use <plan_instance_no> as the immutable key and <client_plan_instance_id> as the mutable client reference.
Use the <transaction_id> field to detect and discard duplicate deliveries. Aria assigns a unique transaction ID to every outbound notification. If your endpoint receives the same <transaction_id> more than once (for example, due to a retry after a network timeout), process the payload only on first receipt and ignore subsequent duplicates.
Always validate the <auth_key> value against the key configured in your Aria account before processing any payload. Reject and log any payload whose <auth_key> does not match your expected value. Do not process payloads from unrecognized sources.
Events that involve contact information—such as events 702, 717, and 736—carry the updated contact values inside named sub-elements (<acct_contact>, <billing_contact>, and <statement_contact> respectively). Each contact block contains a flat set of name, address, phone, and email fields. When processing these events, update only the contact type indicated by the sub-element; the other contact types on the account are not affected.
Events involving queued changes (events 720, 721, 722, 723, 728, 729, 730, and 731) are advance notices of planned changes that have not yet taken effect. Do not apply the change in your downstream system until the corresponding confirmation event fires. The <queued_status_change_date> field tells you when Aria will apply the change, allowing you to schedule preparatory actions in advance.
For events in the dunning state group (events 743, 744, and 745), use the dunning fields to update collections workflows and customer-facing communications. Do not revoke service access based solely on dunning state; wait for an explicit MPI status change event (event 734) before modifying service access in your provisioning system.