Scenario 1: Standard B2B invoice e-invoicing flow

Objective: Confirm that a posted B2B invoice in Zuora results in a valid New Zealand Peppol e-invoice in Avalara and becomes available in the expected download formats.

High-level steps:

1. In Zuora, generate and post an Invoice for a New Zealand B2B customer whose account and sold-to contact meet the e-invoicing prerequisites.

2. Trigger e-invoicing in Zuora so that the invoice is submitted to Avalara.

3. In Avalara, locate the transaction for the New Zealand company and Peppol mandate.

4. Verify that Avalara creates the expected UBL document and that the transaction passes validation.

5. Download the document in XML, PDF, and UBL_XML, where available, and verify the content.

Expected result: Avalara accepts the invoice without blocking validation errors, and all expected download types are available for verification.

Scenario 2: Credit Memo referencing an Invoice

Objective: Verify that Avalara correctly interprets and validates Credit Memos sent from Zuora that reference an existing invoice in the New Zealand Peppol flow.

High-level steps:

1. In Zuora, create and post a Credit Memo that references a previously posted Invoice.

2. Trigger e-invoicing for the Credit Memo.

3. In Avalara, verify that a new Peppol document is created for the Credit Memo.

4. Confirm that the document references the original invoice according to the implemented mapping design.

5. Download the output and verify the adjustment amounts and references.

Expected result: Avalara recognizes the Credit Memo as an adjustment to an existing invoice and processes it successfully.

Scenario 3: Debit Memo e-invoicing

Objective: Validate Avalara's handling of Debit Memos for additional charges after the original invoice.

High-level steps:

1. In Zuora, create and post a Debit Memo for the same New Zealand customer and business region used in the standard invoice scenario.

2. Trigger e-invoicing so that the Debit Memo is sent to Avalara.

3. In Avalara, verify that a new UBL document is created for the Debit Memo.

4. Confirm that buyer and seller information, amounts, and references are correct.

5. Download the available document formats for review.

Expected result: Avalara successfully ingests and validates the Debit Memo as an additional transaction for the same trading relationship.

Scenario 4: Validation failures and data quality checks

Objective: Use Avalara validation results to identify data or mapping issues before production go-live.

Suggested negative tests:

• Submit a transaction with missing seller or buyer information

• Submit a transaction with missing or inconsistent endpoint or routing values

• Trigger e-invoicing for a billing document that is not in Posted status

• Submit a transaction with incomplete template data for required fields

Expected result: Avalara clearly identifies validation failures so that you can correct data or mapping issues in Zuora and retest.

Scenario 5: Resubmission, resync, and regeneration

Objective: Confirm that the operational recovery pattern works as expected after a failed validation or corrected data submission.

High-level steps:

1. Intentionally fail a document by using one of the negative tests.

2. Correct the underlying issue in Zuora.

3. Re-trigger e-invoicing.

4. In Avalara, verify that the corrected document reflects the latest state and that the transaction history is understandable for operations.

5. Download the corrected output and compare it with the earlier failed version.

Expected result: Your team can follow a clear operational pattern for resubmission and reconciliation between Zuora and Avalara.

Scenario 6: Cancellation and known limitations

Objective: Understand how cancellation or reversal scenarios should be handled for New Zealand transactions in your Avalara-based flow.

High-level steps:

1. In Zuora, execute the cancellation or reversal flows that are relevant to your business.

2. Observe how these actions are submitted to Avalara.

3. In Avalara, verify how the follow-up documents, statuses, or corrections are represented.

4. Document any manual steps, product limitations, or agreed operational workarounds before go-live.

Expected result: You have a documented approach for handling reversals or corrections in your New Zealand implementation and have captured any known limitations in the operational runbook.