Release 73

All-Line Rebill: Edit All Original Invoice Lines During a Rebill (DEV-12430)

Aria adds an all-line rebill scheme that lets you reissue a rebill invoice containing every line from the original invoice, including discounts and service credits, instead of only the net charge lines. This lets you correct an invoice while preserving its original discount and service credit associations. A new client parameter specifies rebill behavior.

A new client-level parameter, Enable All Invoice Lines Edit for Rebill, controls the scope of editable invoice lines on a rebill invoice. This parameter is available under Configuration > Invoice Settings in the Aria Crescendo user interface. When you set this parameter to False (the default), only net charges are editable during a rebill, and Aria excludes discounts and credits, preserving current behavior. When you set this parameter to True, Aria allows editing across all invoice line types, including charges, discounts, and service credits.

With the all-line rebill scheme enabled, you can edit the unit amount, service number, and line comments on a service credit line, and Aria issues a new service credit using the same reason code and attributes as the original. You can edit the amount and line comments on a discount line, and Aria applies the original discount definition to the new transaction rather than creating a new discount or coupon. Aria also accepts decimal unit values (for example, 0.5) on rebill line items. Aria preserves the original invoice's line sequencing, and any invoice line you do not include in your rebill input remains unchanged on the new invoice.

If the total discounts and credits on a charge line would exceed the charge line amount, Aria rejects the rebill with an error rather than creating an invalid invoice.

Reset Bill Anniversary on Contract Cancellation with a Prorated Final Invoice (DEV-12434)

When a contract of the type "Terminate Service and Billing and Prorate Final Invoice" ends, Aria issues a prorated final invoice for the final billing period and cancels the plan instance. If your customer decides to remain active after this cancellation, you can remove the cancellation contract from the account. By default, Aria resets the account to the next standard billing period rather than the customer's original bill anniversary date.

Aria provides a client parameter that lets you credit the prorated final invoice and regenerate a full-period invoice instead, so that the customer's original bill anniversary date is preserved. The full-period invoice reflects the plan instance's current state, including any plan or unit changes you made while the customer was deciding whether to stay.

This behavior applies to the following APIs:

• cancel_instance_contract_m
• cancel_acct_universal_contract_m

The ACTION_ON_CANCELLING_CONTRACT_HAVING_FINAL_PRORATED_INVOICE client parameter, in the Contracts parameter group, controls this behavior:

• Set to 0 (default): Aria follows the existing behavior. Canceling the contract resets the bill anniversary date to the next standard billing period.
• Set to 1: Aria issues a credit memo for the prorated invoice lines and generates a full-period invoice for the plan instances under the contract, preserving the original bill anniversary date.

When Aria cannot fully reset an invoice during cancellation, the cancel_instance_contract_m and cancel_acct_universal_contract_m APIs return a <contract_final_invoice_cancel_errors[]> array describing each affected invoice. Each entry in the array includes the following fields:

• <invoice_no>
• <error_code>
• <error_msg>

Usage Pooling Counter Resets During Invoice Void (DEV-12556)

When you void an invoice for a customer with both usage accumulation and usage pooling enabled, Aria reduces the usage pooling counter for each affected plan instance by the units billed on that invoice. This keeps the counter accurate for future billing cycles and prevents pooling calculations from using an inflated usage total.

Aria calculates the adjustment using only usage from services with Standard or Volume Discount tier pricing. This matches the rules Aria applies when it adds usage to the pooling counter during invoice generation, so the void reversal mirrors what was added at invoice acceptance.

Aria does not modify the usage pooling counter when you void an invoice in either of these cases:

• The affected plan instance does not have usage pooling enabled.
• The customer's account does not have usage accumulation enabled.

Aria Internal E-Invoicing Support (UI) (DEV-12573)

Aria now supports internal electronic invoicing (e-invoicing) to help you realize greater billing efficiency, cost savings, faster payments, and compliance with European e-invoicing standards. Once enabled for your account, Aria automatically emails an XML file and a PDF document to your account holders, based on your client-configured e-invoicing email template. By default, only invoices with Aria-managed tax lines are included; you can choose to include all invoices instead.

To enable this feature and configure the required client parameters, contact your Aria representative.

• A new Electronic Invoice (EI) email template class, used exclusively for e-invoicing.
• A new batch process that automatically emails an XML file and a PDF version of each qualifying invoice to the account holder, using your configured EI template.
• New client parameters controlling whether e-invoicing applies only to invoices with Aria-managed tax lines, or to all invoices.
• A VAT Registration Number field on the Company Profile.
• An email address field for Legal Entities.
• Support for storing a Government Invoice ID (Leitweg-ID) at the account and billing group level, for German public-sector e-invoicing.
• The ability to assign the EI (and Invoice/Credit Note) email templates to an account in a single API call.

You can now create and manage an Electronic Invoice (EI) email template from the Email Templates admin screen. The EI template supports XML content only and includes dedicated sections—template body, payment application, tax line, and invoice line—each with its own reference replacement strings, so you can build and maintain the e-invoicing XML independently by section.

Once e-invoicing is enabled for your account, Aria generates and emails the e-invoice for each qualifying invoice after your regular statement delivery completes. Each email includes both the XML file and a PDF rendering of the invoice, sent to the account's statement contact (or billing/admin contact if no statement contact is on file).

By default, Aria sends e-invoices only for invoices containing Aria-managed tax lines. You can choose to have Aria send e-invoices for all invoices regardless of tax lines, using a client parameter setting. Contact your Aria representative to enable e-invoicing and configure this setting.

A VAT Registration Number field is now available on the Company Profile, viewable and editable from the Company Profile screen or via the Company Profile API. Aria uses this value as the seller's tax identification on e-invoices when a Legal Entity VAT number isn't available.

You can now add an email address to a Legal Entity from the Legal Entity screen or via the Legal Entity API. Aria uses this address as the seller's contact on e-invoices for accounts assigned to that Legal Entity.

For accounts requiring German public-sector e-invoicing, you can now store a Government Invoice ID (Leitweg-ID) at the account level, the billing group level, or both. When both are set, Aria uses the billing group value. Aria includes this value on the e-invoice so it can be routed to the correct public-sector recipient.

You can now assign the Invoice, Credit Note, and Electronic Invoice email templates to an account in a single API call instead of setting each template class separately. This replaces the previous single-template fields, which remain available for backward compatibility.

Email template/statement stubs and loops used for e-invoicing

Since the e-invoicing XML invoice rendering consists of multiple logical sections such as Payment Application, Tax Line, and Invoice Line, Aria has introduced dedicated stub sections for the e-invoicing template class to improve manageability and maintainability via the UI. These appear below:

Section	Editor Label	Replacement String Header
Main XML content	Template body	E-Invoicing Inputs
Payment Details (stub 1)	Payment Application	Payment Application Inputs
Tax Breakdown Details (stub 2)	Tax Line	Tax Line Inputs
Invoice Line-item Details (stub 3)	Invoice Line	Invoice Line Inputs

The following replacement strings are available for use in e-invoicing (EI) templates:

Header

UBL field	Replacement string	Source	Notes
ID (invoice no)	insertGLInvNo	gl.invoice_no
IssueDate	insertGLBillDate	gl.bill_date	Format YYYY-MM-DD
DueDate	insertGLDueDate	gl.due_date	Format YYYY-MM-DD
InvoicePeriodStartDate (new for EI templates)	insertGLOverallFromDate	gl.from_date	Format YYYY-MM-DD
InvoicePeriodEndDate (new for EI templates)	insertGLOverallToDate	gl.to_date	Format YYYY-MM-DD
DOcumentCurrencyCode + all @currencyID	insertUpperCurrencyCode	gl.currency	ISO 4217, upper-cased
BuyerReference	insertBuyerReference	acct.acct_no	Same token reused for Buyer PartyIdentifiction/ID

Seller

All-or-nothing precedence: when the account has a Legal Entity (LE) assigned, all 7 Seller address tokens are sourced from client_legal_entity; otherwise, all 7 fall back to client. Per-field mixing between the two sources is not permitted.

UBL field	Replacement string	Source	Notes
PartyIdentification/ID	insertClientNo	client.client_no
Party Name/Name PartyLegalEntity/ RegistrationName	insertClientName	client.client_name
EndpointID	insertSellerEmail	LE email/Client billing_email	schemeID EM
PostalAddress/StreetName	insertSellerAddress1	LE/Client address1
AdditionalStreetName	insertSellerAddress2	LE/Client address2
CityName	insertSellerCity	LE/Client city
PostalZone	insertSelletZip	LE postal_code/Client postal_code
CountrySubentity	insertSellerStateProv	LE state/Client state_prov
Country/IdentificationCode	insertSellerISOCountry	LE/Client country	Must be ISO 3166-1 alpha-2 (e.g. GB)
PartyTaxScheme/CompanyID	insertSellerVatId	LE/Client vat_registration_no	Must be country=prefixed (e.g. GB123...); free-text input

Buyer

UBL field	Replacement string	Source	Notes
PartyTaxScheme/CompanyID	insertBuyerVatId	acct.taxpayer_id	Must be country-prefixed; free-text input
PartyName/Name PartyLegalEntity/ RegistrationName	insertBuyerCompanyName	acct_address.company_name
PostalAddress/StreetName	insertBuyerAddress1	acct_address.address1
AdditionalStreetName	insertBuyerAddress2	acct_address.address2
CityName	insertBuyerCity	acct_address.city
PostalZone	insertBuyerZip	acct_address.zip
CountrySubentity	insertBuyerStateProv	acct_address.state
Country/IdentificationCode	insertBuyerISOCountry	acct_address.country	Must be ISO 3166-1 alpha-2
Contact/Name	insertBuyerFirstName + insertBuyerLastName	acct_address.first_name , last_name	Concatenated
Contact/Telephone	insertBuyerIntlPhone	acct_address.intl_phone
Contact/ElectronicMail	insertBuyerEmail	acct_address.email

Buyer address precedence: acct_billing_group.statement_address_seq > billing_info.bill_address_seq > acct.acct_address_seq.

Payment Means (per payment)

UBL field	Replacement string	Source	Notes
PaymentID	insertPaymentReference	payments.payment_id
PaymentMandate/ID	insertDirectDebitMandateId	billing_info.mandate_id
PaymentMandate/PayerFinancialAccount/ID	insertBankIdCd	billing_info.bank_id_cd
PayeeFinancialAccount/ID	insertBankAcctSuffix	billing_info.suffix	Masked: LPAD(suffix,16,'*') —16 chars, last 4 visible

Invoice Line

UBL field	Replacement string	Source	Notes
InvoiceLine/ID	insertLineItemNo	gl_detail.seq_num
LineExtensionAmount	insertItemAmount	gl_detail.debit	fmt_ubl_num, 2 decimal point
InvoicedQuantity	insertItemUnits	gl_detail.usage_units	Needs @unitCode (default EA) in template
Price/PriceAmount	insertItemRate	gl_detail.usage_rate	Client rate scale: USAGE_/RECURRING_RATE_PER_UNIT_SCALE, else currency scale
Item/Name	insertItemPlanName	gl_detail.plan_name
Item/Description	insertItemSimpleLabel	gl_detail.comments
ClassifiedTaxCategory/Percent	insertItemTaxRate	SUM(gl_tax_detail.tax_rate) for the line	x 100 (stored fraction > percentage)

Tax Breakdown

UBL field	Replacement string	Source	Notes
TaxSubtotal/TaxableAmount	insertTaxSubtotalTaxableAmount	MAX(gl_detail.debit) of taxed line	MAX is constant within the group
TaxSubtotal/TaxAmount	insertTaxSubtotalTaxAmount	SUM(gl_tax_detail.debit)	Signed —+ve on charges, - ve on credits
TaxCategory/Percent	insertTaxSubtotalPercent	SUM(gl_tax_detail.tax_rate)	x 100; SUM handles compoint tax
TaxTotal/TaxAmount	insertTaxTotalTaxAmount	Sum of all subtotal tax amounts	Signed

Monetary Totals

UBL field	Replacement string	Source	Notes
LineExtensionAmount (BT-106) and TaxExclusiveAmount (BT-109)	insertInvoiceNetAmount ExcludingTax (no break above - edited for presentation only)	SUM(gl_detail.debit) where services.is_tax !=1	One token feeds both elements
TaxInclusiveAmount (BT-112)	insertInvoiceNetAmount IncludingTax (no break above - edited for presentation only)	line-ext + total tax
PayableAmount (BT-115)	insertGLBalDue	gl.debit - gl.credit	Balance after applied payments

Statement Sequence Strings

UBL field	Replacement string	Source	Notes
(statement seq)	insertAcctStatementSeqStr	acct_statement.acct_statement_seq_str
(second statement seq)	insertSecondAcctStatementSeqStr	acct_statement.second_acct_statement_seq_str

API-related enhancements for this feature also appear on this page.

To enable e-invoicing for your account, along with configuring the client parameters that control which invoices are eligible, contact your Aria representative.

Prorated Invoicing When a Type 7 Contract Ends Mid-Period (DEV-12627)

When you call update_acct_plan_multi_m to assign a plan instance to an account with an active prorate-terminate (Type 7) contract that ends before the regular billing anniversary, Aria caps the billing period at the contract end date. The invoice line reflects only the days remaining in the cycle up to the contract end date, and the next bill date resumes on the regular anniversary. Aria records the resulting invoice against the contract so that contract cancellation rollback handles it correctly. This prevents Aria from billing for periods contracts do not cover, so you do not need to issue manual refunds.

This behavior applies only to prorate-terminate (Type 7) contracts. If no active Type 7 contract applies to the plan instance, invoicing behaves as it did before.

• When is set to 1 (full invoice), is not provided, and an active Type 7 contract caps the billing period, Aria generates a prorated invoice.
• When is set to 1 (full invoice), is not provided, and no contract cap applies, Aria generates a full-period invoice.
• When is set to 2 (prorated invoice) and falls later than the contract end date, Aria caps the period at the contract end date instead of the override date. If no active Type 7 contract exists for the plan instance, Aria processes the override date as provided.
• When is provided and is not 0, invoicing behavior is unchanged.

When the cap applies and you do not provide an override bill-through date, Aria prorates the charge as follows.

• Proration factor: days to bill divided by the natural cycle days. For example, a period from April 1 through April 15 capped within an April 1 through April 30 cycle produces a factor of 15/30, or 0.5.
• The last bill-through date is set to the contract end date.
• The next bill date resumes on the regular anniversary.

When you provide an override bill-through date that falls later than the contract end date, Aria applies the same cap.

• The last bill-through date is set to the contract end date rather than the override date.
• The next bill date is set to the override bill-through date plus one day, consistent with the existing override path.

Aria calculates proration using the calendar-month natural cycle. For example, a period from February 1 through February 15 in a 28-day February produces a factor of 15/28, or approximately 0.5357.

When the cap applies, Aria sets the field on the resulting contract final invoice record to indicate a Type 7 capped invoice. Aria does not change how it sets this field for other contract-modification invoice types.

When a single call to update_acct_plan_multi_m includes multiple plan assignments, Aria applies the cap independently to each plan. If one plan in the batch meets the Type 7 cap conditions and another does not, Aria prorates only the plan that meets the conditions and leaves the other plan unaffected.

Aria applies the same Type 7 contract cap to plans activated through the Process Plans in Queue batch for future-dated plan activations.

Aria makes no changes to the input parameters of update_acct_plan_multi_m.

Payment Plans Phase 8: Client-Level Payment Plan Terms and Automatic Cancellation on Missed Payments (DEV-12656)

Aria extends payment plans with two capabilities: a reusable, client-level payment plan template called a payment plan term, and an option to automatically cancel a payment plan after a configurable number of missed installments. This writeup describes automatic cancellation of payment plans on missed payments.

Aria can now automatically cancel a payment plan after it accumulates a set number of missed installments. Configure this behavior using the Auto-Cancel Payment Plan on Missed Payments parameter under Configuration > Payments > Payment Settings. Set this parameter to an integer from 0 to 99. Aria increments the missed payment count each billing cycle that a payment plan installment fails to collect in the Billing Manager or Dunning Manager batch and the overdue balance remains unpaid. Aria resets the count only when you pay the full overdue balance. A partial payment does not reset the count. Set the parameter to 0 to disable automatic cancellation. When the count reaches the configured threshold, Aria cancels the payment plan and adds an account comment recording the cancellation and the threshold reached.

CCP Option To Resend Statements To A New Email Address (DEV-12689)

In the Customer Care Portal (CCP), you can now edit recipients before resending a statement or communication. Previously, resending a statement or other customer communication would send it only to the recipients already on file for the account, with no way to redirect or add recipients at the point of resending.

Now, before resending you can directly edit who receives the communication and add multiple To recipients plus Cc and Bcc recipients, including ad-hoc email addresses that are not already saved as account contacts. Addresses are validated inline and invalid entries are flagged before the communication can be resent. The established recipient length limits are enforced (900 characters for To; 200 characters each for Cc and Bcc).

OneSource Smart Tax Integration Enhancements (DEV-12704)

Aria's integration with the OneSource tax service now sends enhanced transaction data, improving tax determination for clients doing business in Canada, Germany, India, and other jurisdictions with detailed reporting requirements. Aria now transmits customer identification, delivery terms, address details, tax registration numbers, and line-item product identifiers to OneSource, improving tax calculation accuracy, exemption certificate matching, and audit reporting.

Aria now sends customer number and customer name to OneSource on tax, post, refund, and void requests, so exemption certificates and VAT registration group members can be matched correctly.

You can configure a default customer number in the OneSource tax configuration, with the option to override it per account using a supplemental field (Configuration > Integrations > Taxation Configuration > Configuration tab). If no value is configured, Aria omits the field from the request. Customer name is populated from the account's company name, falling back to first and last name when the company name field is empty.

Aria now sends delivery term and delivery term type to OneSource, providing greater detail on tax point determination for cross-border transactions.

Two new configuration fields—Delivery Term (free text) and Delivery Term Type (dropdown: Incoterms, POTT, or empty)—are available in the OneSource tax configuration, both with supplemental field override support (Configuration > Integrations > Taxation Configuration > Configuration tab). If neither field is configured, the delivery term is omitted from the request.

Aria now sends ATTRIBUTE2, 3, 7, 8, and 30 to OneSource, enabling invoice reconciliation, source-system identification, end-to-end request correlation, and product-level reporting.

New configuration fields for ATTRIBUTE2, 3, 7, and 8 are available in the Main Configuration (document level); ATTRIBUTE30 is configured in the Group Configuration tab (line-item level). When a field isn't explicitly configured, Aria applies default values:

• ATTRIBUTE2—invoice creation date
• ATTRIBUTE3—invoice number
• ATTRIBUTE7—hardcoded to "AriaCore"
• ATTRIBUTE8—the Correlation-Id value sent with the request

ATTRIBUTE30 has no default value and is omitted from the request if left unconfigured.

In addition to the shipFrom and shipTo addresses Aria already sends, Aria now sends sellerPrimary, buyerPrimary, and supply addresses at both the document and line-item levels, resolving tax calculation failures for transactions requiring multiple address types.

sellerPrimary mirrors the shipFrom Address, and supply mirrors the shipTo Address. For buyerPrimary, new configuration options are available at both the Main Configuration (document level) and Group Configuration (line-item level), letting you choose Account Address, Statement Address, or a fallback preference between the two. If no line-item option is configured, Aria falls back to the document-level setting.

Aria now sends seller and buyer tax registration numbers to OneSource, supporting nexus determination and reverse-charge VAT processing for multi-jurisdiction transactions.

New free-text configuration fields accept comma-separated registration numbers, which Aria converts into an array before sending. The buyer registration field supports a supplemental field override. If no values are configured, Aria sends an empty array rather than omitting the field.

Aria now sends the isCredit and isAuditUpdate field names so OneSource properly recognizes credit memos and audit updates. isCredit is set to false for all transaction types; isAuditUpdate is set to true for post, void, and refund transactions, and false for quotes.

Aria now sends a part number and description with each line item, letting OneSource key tax determination and reporting off your own product and plan identifiers.

Two new dropdown fields are available in the Group Configuration tab:

• LineItem/PartNumber—Client Plan Identifier or Client Service Identifier
• LineItem/Description—Plan Name or Service Name

Value resolution depends on line type—plan lines resolve from the plan, one-time order lines resolve from the item, and service lines resolve from the service. If a field is left unselected, Aria omits it from the request.

Prevent Voiding of Payments with Active Refunds (DEV-12714)

Aria can now block the voiding of a payment that has an active refund applied to it, whether the refund is partial or full. This prevents the system from crediting your customers twice for the same transaction (once through the refund and again through the void).

• void_transaction_m

A new client parameter, Prevent Void on Refunded Payments, is available under Payment Settings (Configuration > Payment > Payment Settings). This parameter is a Boolean value and defaults to FALSE, so existing account behavior does not change unless you enable it.

When you set Prevent Void on Refunded Payments to TRUE, the void_transaction_m API checks whether the payment has at least one active, non-voided refund before allowing the void. If an active refund exists, the API returns the following error instead of completing the void: 

Error Code: 2030
Error Message: "This payment has been partially or fully refunded and is not eligible for a void."

This restriction applies dynamically. If you later void the refund transaction, Aria automatically restores the original payment's eligibility for void. The check applies to both check refunds and electronic refunds, and it excludes refunds that have themselves been voided or failed.

When you enable Prevent Void on Refunded Payments, the Payments page displays a lock icon instead of the void icon for any Electronic or External payment that has been partially or fully refunded. A tooltip on the lock icon states that the payment is not eligible for void because it has been partially or fully refunded, and a page-level instruction explains the same to you. If you void the associated refund, Aria removes the lock icon and restores the void action for that payment.

Dunning for Existing Invoices After a Payment Method Change (DEV-12718)

When you change a billing group's payment type from electronic to payment terms after Aria generates an invoice but before that invoice's due date, Aria now considers the billing group's current payment type when deciding whether to enter payment-terms dunning. Previously, Aria evaluated dunning eligibility using only the payment type the invoice carried when it was generated, so these invoices could never enter dunning even after they became past due.

Aria adds a new client parameter, Honor Current Payment Type of Billing Group For Payment Terms Dunning, in the Payment Processing group.

Value	Behavior
True	Aria honors the billing group's current payment type when deciding payment-terms dunning.
False	Aria uses only the invoice's original payment type when deciding payment-terms dunning (prior behavior).

Aria sets this parameter to True by default for new Aria instances. For existing Aria instances, Aria sets this parameter to False on rollout, so current behavior continues unless you choose to enable it.

Billie and Billie Connect Updates (DEV-12753)

This release upgrades Billie and Billie Connect to run on Claude Sonnet 4.6 as the underlying language model, replacing the previous model version to take advantage of improved reasoning and response quality.

Alongside the model upgrade, this release introduces a retry mechanism that automatically re-attempts the request whenever the model returns an empty or blank response, reducing the number of failed or unhelpful conversational turns that users previously experienced. 

In addition, dunning-related queries and utterances have been enhanced: when a user asks about dunning status, Billie now returns both the current dunning step and detailed suspension information for the account. This information is surfaced through a new "Open Table" option in the response, which organizes the results by dunning group and by suspension date, making it easier to scan multiple accounts or steps at once. Notably, the suspension date shown is not static—it is calculated dynamically at query time based on the account's specific dunning configuration (e.g., step durations and grace periods), so the date reflects the most current projection of when suspension would occur if no action is taken.

Aria Internal E-Invoicing Support (API) (DEV-12573)

Aria now supports internal electronic invoicing (e-invoicing) for Aria-managed accounts, helping you meet European e-invoicing requirements such as EN 16931 and XRechnung. Once your Aria representative enables the feature for your account, Aria automatically emails an XML file and a PDF copy of each qualifying invoice based on your configured e-invoicing email template. The account, billing group, and profile management APIs below have been enhanced to support configuring and retrieving the data this feature relies on.

Affected APIs:

Admin Tools APIs	Core APIs
create_legal_entity_m  get_company_profile_m  get_legal_entity_m set_company_profile_m update_legal_entity_m	assign_acct_plan_m  create_acct_billing_group_m  create_acct_complete_m get_acct_billing_group_details_m get_acct_details_all_m get_acct_hierarchy_details_m  update_acct_billing_group_m update_acct_complete_m update_acct_plan_multi_m

You can now assign the template used for e-invoice emails—along with the templates used for standard invoices and credit notes—in a single call to create_acct_complete_m or update_acct_complete_m using the new <email_template_override> input array. Each entry in the array specifies:

• <template_class>—I (Invoice), CN (Credit Note), or EI (Electronic Invoice); defaults to I when not supplied
• <template_no>—the Aria-assigned template number
• <client_template_id>—your own client-defined template identifier

If both <template_no> and <client_template_id> are provided for the same entry, <template_no> takes precedence. Values passed in <email_template_override> take precedence over the <legacy alt_msg_template_no>, <client_alt_msg_template_id>, <cn_alt_msg_template_no>, and <client_cn_alt_msg_template_id> fields when both are supplied in the same call. Those legacy fields continue to work as before when <email_template_override> is not used.

To support values required for jurisdiction-specific e-invoicing—such as the Buyer Reference/Endpoint ID (Leitweg-ID) required for German e-invoicing—you can now store e-invoicing-specific key/value fields on an account or a billing group. A billing group-level value takes precedence over an account-level value of the same field name.

The following input fields are now included:

create_acct_complete_m

Field	Type	Length	Description
<acct_einvoicing_fields>	array
<acct_einvoicing_field_name>	string	100	Name of the account-level e-invoicing field. A flexible text field. It stores the Government Invoice ID (Leitweg-ID) used to route e-invoices to German public sector recipients. Acts as the default value. Overridden if a Billing Group has its own Leitweg-ID set.
<acct_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name.
<bg_einvoicing_fields>	array
<bg_einvoicing_field_name>	string	100	Name of the billing group e-invoicing field. Takes priority over the account level value.
<bg_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name.

create_acct_billing_group_m

Field	Type	Length	Description
<bg_einvoicing_fields>	array
<bg_einvoicing_field_name>	string	100	Name of the billing group e-invoicing field.
<bg_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name.

update_acct_billing_group_m

Field	Type	Length	Description
<bg_einvoicing_fields_updates>	array
<bg_einvoicing_field_name>	string	100	Name of the billing group e-invoicing field to add, update or delete.
<bg_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name (required).
<bg_einvoicing_field_directive>	long	1	Allowable Values Values Description 1 Save/Update (default) 2 Delete

get_acct_billing_group_details_m

Field	Type	Length	Description
<bg_einvoicing_field_list>	array
<bg_einvoicing_field_name>	string	100	Name of the billing group e-invoicing field (government_invoice_id as above).
<bg_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name.

update_acct_complete_m

Field	Type	Length	Description
<acct_einvoicing_field_updates>	array
<acct_einvoicing_field_name>	string	100	Name of the account-level e-invoicing field.
<acct_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name. Required when directive is 1 (Save); ignored when directive is 2 (Delete).
<acct_einvoicing_field_directive>	long	1	Allowable Values Values Description 1 Save/Update (default) 2 Delete
<bg_einvoicing_field_updates> (<billing_groups_array>)	array
<bg_einvoicing_field_name>	string	100	Name of the billing group e-invoicing field. Takes priority over the account level value.
<bg_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name (Required for directive 1 for Save - ignored for 2/Delete).
<bg_einvoicing_field_directive>	long	1	Allowable Values Values Description 1 Save/Update (default) 2 Delete

update_acct_plan_multi_m

Field	Type	Length	Description
<bg_einvoicing_field_updates> (<acct_billing_groups>)	array
<bg_einvoicing_field_name>	string	100	Name of the billing group e-invoicing field.
<bg_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name. Required when directive is 1 for Save; ignored for 2/Delete.
<bg_einvoicing_field_directive>	long	1	Allowable Values Values Description 1 Save/Update (default) 2 Delete

assign_acct_plan_m

Field	Type	Length	Description
<bg_einvoicing_field_updates>	array
<bg_einvoicing_field_name>	string	100	Name of the billing group e-invoicing field.
<bg_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name.

get_acct_details_all_m

Field	Type	Length	Description
<acct_einvoicing_field_list>	array
<acct_einvoicing_field_name>	string	100	Name of the account-level e-invoicing field.
<acct_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name.
<bg_einvoicing_field_list> (<billing_groups_info>)
<bg_einvoicing_field_name>	string	100	Name of the billing group e-invoicing field. Takes priority over the account level value.
<bg_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name.

get_acct_hierarchy_details_m

Field	Type	Length	Description
<acct_einvoicing_field_list>	array
<acct_einvoicing_field_name>	string	100	Name of the account-level e-invoicing field.
<acct_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name.
<bg_einvoicing_field_list> (<billing_groups_info>)
<bg_einvoicing_field_name>	string	100	Name of the billing group e-invoicing field. Takes priority over the account level value.
<bg_einvoicing_field_value>	string	100	The value corresponding to the e-invoicing field name.

The following error messages are now included for the above APIs:

Error Code	Description
1010	Missing field value: "Missing required parameter: bg_einvoicing_field_value"
1016	Unsupported field name: "Invalid input:bg_einvoicing_field_name - <value> is not a supported e-invoicing field name."
5001	Duplicate field name in the array: "Duplicate entries: The array bg_einvoicing_fields contains duplicates in bg_einvoicing_field_name."

create_legal_entity_m and update_legal_entity_m (Input field)

Field	Type	Length	Description
<legal_entity_email>	string	254 characters	Email address for the legal entity contact

get_legal_entity_m (Output field)

Field	Type	Description
<legal_entity_email>	string	Email address for the legal entity contact

get_company_profile_m (Output field)

Field	Type	Description
<vat_registration_no>	string	Specifies the VAT Registration number for e-invoicing

set_company_profile_m (Input and Output field)

Field	Type	Length	Description
<vat_registration_no>	string	30 characters	Specifies the VAT Registration Number for e-invoicing

Application-related details are also included for this feature.

To enable e-invoicing for your account, along with configuring the client parameters that control which invoices are eligible, contact your Aria representative.

Add Surcharge Rate Schedule Details in get_surcharge_details_m Admintool API (DEV-12617)

The get_surcharge_details_m Admin Tool API has been enhanced to return full surcharge rate schedule details in a new <surcharge_rate_schedule_details> array that provides a more complete picture of the rate schedule tied to the surcharge. This array includes schedule name, currency, default indicator, an ordered list of rate tiers with sequence numbers, unit range for the rate tiers, rate per unit, and tier description. Existing locale and translation input parameters are honored for schedule and tier names. Additionally, this change is backward-compatible meaning the existing <surcharge_tier> field, which existing integrations may already depend on, remains unchanged and continues to return data. This new array is included in the get_surcharge_details_m API output automatically.

Extend get_dunning_processes_m To Return Step Configuration Details Via Optional include_dunning_steps Flag (DEV-12640)

The get_dunning_processes_m Admintools API now supports an optional <include_dunning_steps> input field. When this flag is set to true in the request, the API response now includes full configuration detail for every step in the dunning process, rather than just the high-level process summary that was previously returned.

For each step, the response provides the step's duration, the notification template used, the email destination configured for that step, the fee type and fee amount (if any) associated with the step, an indicator of whether the step performs a collection action, and a human-readable description of the step. In addition to per-step detail, the response now also indicates whether the dunning process applies to all subscriptions on the account or only to specific ones, and it returns the notification template tied to the final suspension step specifically, since that step is often handled differently than the earlier notification-only steps.

Separately, this release corrects the <total_step_count> field description to clarify that the <total_step_count> reflects only the notification/collection steps and excludes the final suspension step.

Payment Plans Phase 8: Client-Level Payment Plan Terms and Automatic Cancellation on Missed Payments (DEV-12656)

Aria extends payment plans with two capabilities: a reusable, client-level payment plan template called a payment plan term, and an option to automatically cancel a payment plan after a configurable number of missed installments. Aria created or enhanced the following APIs to support these features:

• create_payment_plan_term_m (new API)
• get_payment_plan_terms_m (new API)
• edit_payment_plan_term_status_m (new API)
• create_payment_plan_m
• update_payment_plan_m

A payment plan term is a reusable payment plan configuration that you define once at the client level instead of specifying the same values on every individual payment plan. Each payment plan term supports either an independent schedule with its own length, period type, and payment interval, or a schedule aligned to a master plan instance (MPI) anniversary statement.

Use the create_payment_plan_term_m API to build a library of payment plan terms for your client, each identified by a field. Use get_payment_plan_terms_m to retrieve your existing payment plan terms, and use edit_payment_plan_term_status_m to set one or more payment plan terms to active or inactive. Setting a term to inactive prevents you from using it on new payment plans without deleting it, and you can reactivate it later. Status changes do not affect payment plans you already created from the term.

Aria enhances the create_payment_plan_m API so you can pass a field to create an account-level payment plan directly from a payment plan term, instead of specifying every plan parameter in the call. You can still override individual fields on the account-level plan, or remove an optional field by passing a value of -9999. Aria also adds a flag to the update_payment_plan_m API.

Field Name	Type	Description
<payment_plan_term_no>	long	Aria-assigned unique identifier for the payment plan term to apply to this payment plan. Alternative field: client_payment_plan_term_id.
<client_payment_plan_term_id>	string	Client-defined identifier for the payment plan term to apply to this payment plan. Alternative field: payment_plan_term_no.

Field Name	Type	Description
<recalculate_date>	string	Recalculates future notify dates and days until due for an independent payment plan. Allowable values are Y (yes) and N (no, the default). Aria treats a null value, or any value other than Y, as N.