Scenario 1: Standard B2B invoice e‑invoicing flow

Objective: Confirm that a posted B2B Invoice in Zuora results in a valid Peppol e‑invoice in Avalara, passing Avalara's Australian validations and becoming available for Peppol distribution.

High-level steps:

1. In Zuora, generate and post an Invoice for an Australian B2B customer whose account and sold-to contact meet all e‑invoicing prerequisites.

2. Trigger e‑invoicing in Zuora so that the invoice is submitted to Avalara as a Peppol transaction.

3. In Avalara E‑Invoicing and Live Reporting:

   • Locate the transaction under the Australian company and Peppol mandate.

   • Verify that Avalara has created a UBL Peppol document with the expected seller and buyer identification, including ABN and Peppol destination code.

4. Review Avalara validation results and statuses to ensure the invoice is considered valid and ready for delivery.

5. Download the document in XML, PDF, and UBL_XML (where available) from Avalara and confirm that the structure and content match expectations.

Expected results:

• Avalara accepts the invoice without blocking validation errors.

• The Peppol UBL document contains consistent seller and buyer data, including ABN-based identifiers.

• All configured download types are available in Avalara and usable by your downstream processes.

Scenario 2: Credit Memo referencing an Invoice

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

High-level steps:

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

2. Trigger e‑invoicing for the Credit Memo.

3. In Avalara:

   • Confirm that a new Peppol document is created for the Credit Memo.

   • Verify that it references the original Invoice according to the Peppol and Avalara mapping design (for example, prior invoice identifier and dates).

4. Check Avalara validations and workflow status to ensure the Credit Memo is correctly classified and routed.

5. Download the UBL document (and other formats as needed) and confirm that monetary amounts and references reflect the intended adjustment.

Expected results:

• Avalara recognizes the Credit Memo as an adjustment to an existing Invoice, not as a standalone unrelated invoice.

• Validation and routing are successful, with clear references to the original document in the Peppol payload.

Scenario 3: Debit Memo e‑invoicing

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

High-level steps:

1. In Zuora, create and post a Debit Memo for the same Australian customer and business region used in Scenario 1.

2. Trigger e‑invoicing in Zuora so the Debit Memo is sent to Avalara.

3. In Avalara:

   • Confirm that a new Peppol UBL document exists for the Debit Memo.

   • Review that buyer/seller information and fiscal data align with the original invoice and local rules.

4. Assess Avalara validations, statuses, and any mandated Peppol responses for this incremental charge.

5. Download available document formats and confirm that amounts and references are additive and consistent with your accounting expectations.

Expected results:

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

• Peppol payloads and Avalara responses clearly represent the increased receivable.

Scenario 4: Validation failures and data quality checks

Objective: Use Avalara's validation outcomes to harden your data and configuration before production, by intentionally sending incomplete or incorrect data from Zuora.

Suggested negative test variations - send test transactions where:

• The seller ABN or buyer ABN is missing, invalid, or inconsistent between Zuora and Avalara configuration.

• The E‑Invoice Destination Code or Destination Code Schema Id is missing or does not match the Peppol ID scheme registered in Avalara.

• The billing document in Zuora is not in Posted status when e‑invoicing is triggered.

What to verify in Avalara

• How Avalara flags and surfaces validation failures for Australian Peppol documents (errors vs warnings, codes, and descriptions).

• Whether rejected documents can be filtered, reported, and exported for remediation workflows.

• How quickly corrected documents (after fixing data in Zuora) can be re-submitted and re-validated.

Expected results:

• Avalara clearly identifies which fields cause validation failure, enabling you to refine Zuora mappings and master data.

• Your operational team understands which errors must be fixed in Zuora versus which can be managed or overridden in Avalara, where applicable.

Scenario 5: Resubmission, resync, and regeneration from Avalara's view

Objective: Confirm that Avalara behaves as expected when documents are re‑sent from Zuora after data corrections, and that Avalara's audit and status history remain consistent.

1. Intentionally cause one or more documents to fail validation in Avalara using the negative tests from Scenario 4.

2. Correct the underlying issue in Zuora (for example, updating ABN, destination code, or other mapped fields) and re-trigger e‑invoicing.

3. In Avalara:

   • Verify that new versions or replacement documents are created as designed.

   • Confirm that status transitions (from failed to accepted) and any Peppol-level responses are captured in Avalara's audit trails.

4. Download the corrected documents and compare them to the initial failed versions to confirm that data changes appear as expected.

Expected results:

• Avalara reliably reflects the latest, corrected state of each transaction.

• You have a clear operational pattern for resubmission and reconciliation between Zuora and Avalara.

Scenario 6: Cancellation and known limitations

Objective: Understand how Avalara handles cancellation or reversal scenarios originating from Zuora for Australian Peppol flows, and document any gaps or manual steps required.

High-level steps:

1. In Zuora, execute cancellation or reversal flows that are relevant to your business (such as full or partial reversals of invoices or memos).

2. Observe how these actions are translated into subsequent submissions to Avalara (for example, additional corrective documents vs logical cancellation).

3. In Avalara:

   • Verify how cancellations or reversals are represented, including any specific Peppol message types or statuses.

   • Identify whether there are scenarios where cancellation must be handled manually or according to local policies.

4. Collaborate with Avalara and your tax advisors to confirm compliant handling and to document the agreed pattern.

Expected results:

• You have a documented, compliant approach for handling cancellation and reversal scenarios in Avalara for Australia.

• Any known limitations or manual workarounds are captured in your operational runbook for Avalara and Zuora.