Scenario 1: Standard B2B invoice e-invoicing flow

Objective: Confirm that a posted B2B invoice in Zuora results in a valid Austria PEPPOL e-invoice in Avalara and becomes available in the supported Austria download formats.

High-level steps:

1. In Zuora, generate and post an invoice for an Austria customer whose business region and e-invoicing profile are configured with the required Austria identifiers.

2. Trigger e-invoicing so that the invoice is submitted to Avalara by using the PEPPOL process.

3. In Avalara, verify that the transaction is created under the Austria company and PEPPOL mandate.

4. Download the resulting file in XML, PDF, or UBL_XML as needed and verify the content.

Expected results: Avalara accepts the invoice without blocking validation errors, and the Austria transaction is available in the expected supported download formats.

Scenario 2: Credit memo referencing an invoice

Objective: Verify that Avalara correctly processes a credit memo for Austria when the credit memo references an existing invoice in the PEPPOL flow.

High-level steps:

1. In Zuora, create and post a credit memo that references a previously posted Austria invoice.

2. Trigger e-invoicing for the credit memo.

3. In Avalara, confirm that a new Austria PEPPOL document is created and that the document can be downloaded in the supported output formats where applicable.

Expected results: Avalara classifies the credit memo correctly and preserves the relationship to the original invoice.

Scenario 3: Debit memo e-invoicing

Objective: Validate Avalara's handling of Austria debit memos that represent additional charges after an original invoice.

High-level steps:

1. In Zuora, create and post a debit memo for the same Austria trading relationship used in the invoice scenario.

2. Trigger e-invoicing in Zuora so that the debit memo is sent to Avalara.

3. In Avalara, confirm that the debit memo is created as a PEPPOL document and can be downloaded in the supported Austria output types where applicable.

Expected results:

Avalara successfully ingests and validates the debit memo as an additional Austria PEPPOL transaction.

Scenario 4: Validation failures and data quality checks

Objective: Use Avalara validation results to identify incorrect Austria setup values before you move to production.

Suggested negative tests

• Submit a transaction with a missing or invalid Austria VAT/GLN number.

• Submit a transaction with an incorrect schema ID instead of the Austria value 0088.

• Submit a transaction with missing or incorrect e-invoice destination code values.

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

Expected results: Avalara clearly identifies the field or setup issue that caused the validation failure, allowing you to correct the data in Zuora and re-submit the transaction.

Scenario 5: Resubmission, resync, and regeneration

Objective: Confirm that Austria transactions behave as expected when you correct source data in Zuora and submit the transaction again to Avalara.

High-level steps:

1. Cause a validation failure by using one of the negative tests above.

2. Correct the identifier or setup data in Zuora.

3. Re-trigger e-invoicing and verify the updated transaction in Avalara.

Expected results: Avalara reflects the latest corrected state of the Austria transaction, and the corrected document can be downloaded in the expected format.

Scenario 6: Cancellation and operational handling

Objective: Understand how cancellation or reversal scenarios are handled for Austria transactions and document any operational limitations or manual handling steps required for your implementation.

High-level steps:

1. Execute the relevant reversal or cancellation flow in Zuora for an Austria invoice or memo.

2. Observe how the follow-up transaction appears in Avalara and whether additional operational handling is required.

3. Document the agreed operational procedure for resync, regenerate, download, and exception handling for Austria.

Expected results: Your team has a documented operational approach for Austria reversal and exception handling in Avalara and Zuora.