Scenario 1: Standard B2B invoice e-invoicing flow

Objective: Confirm that a posted B2B invoice in Zuora results in a valid Denmark PEPPOL e-invoice in Avalara.

High-level steps:

1. In Zuora, generate and post an invoice for a Denmark 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.

3. In Avalara, locate the transaction under the Denmark configuration and verify that the expected PEPPOL/UBL document is created.

4. Review the validation result and confirm that the document is ready for downstream processing.

5. Download the document in the supported formats and verify the output.

Expected results:

• Avalara accepts the invoice without blocking validation errors.

• The document contains consistent seller and buyer identification data.

• The supported download formats are available as expected.

Scenario 2: Credit memo referencing an invoice

Objective: Verify that a credit memo submitted from Zuora is processed correctly in the Denmark flow and references the original invoice appropriately.

High-level steps:

1. Create and post a credit memo in Zuora for an invoice that was already submitted successfully.

2. Trigger e-invoicing for the credit memo.

3. In Avalara, verify that the credit memo is created as a new PEPPOL document.

4. Confirm that references to the original invoice are present where required by the mapping design.

5. Review the output and validation results.

Expected results:

• Avalara recognizes the credit memo as an adjustment to the original invoice.

• References and monetary amounts are consistent with the intended correction.

Scenario 3: Debit memo e-invoicing

Objective: Validate that debit memos are processed correctly for Denmark.

High-level steps:

1. Create and post a debit memo in Zuora for the same Denmark customer.

2. Trigger e-invoicing submission.

3. In Avalara, verify that the debit memo is generated and validated in the expected Denmark flow.

4. Download the generated output and review the document details.

Expected results:

• Avalara ingests and validates the debit memo successfully.

• The resulting document reflects the additional amount correctly.

Scenario 4: Validation failures and data quality checks

Objective: Use negative testing to identify data-quality issues before production rollout.

Suggested negative variations:

• Missing or invalid seller identifier

• Missing or invalid buyer identifier

• Missing or inconsistent electronic address information

• Incorrect or incomplete master data in Zuora

• Attempting to trigger e-invoicing before the billing document is posted

Expected results:

• Avalara clearly identifies validation failures.

• Your team can determine whether remediation is required in Zuora data, field mapping, or Avalara setup.

Scenario 5: Resubmission after correction

Objective: Confirm that corrected documents can be resubmitted successfully after an initial validation failure.

High-level steps:

1. Intentionally submit a document with incomplete or invalid data.

2. Review the error in Avalara.

3. Correct the issue in Zuora or in the relevant configuration.

4. Resubmit the document.

5. Verify that the corrected document is accepted and that the processing history remains traceable.

Expected results:

• The corrected document is processed successfully after resubmission.

• Your operational team can trace the failure and recovery path clearly.