Scenario 1: Standard invoice e-invoicing flow

Objective: Confirm that a posted invoice in Zuora results in a valid Italy e-invoice in Avalara using the supported Italy package configuration.

High-level steps:

1. Create and post an invoice in Zuora using the Italy business region and a fully configured customer profile.

2. Trigger e-invoicing in Zuora.

3. In Avalara, locate the transaction for Italy.

4. Verify that the document is generated using the supported Italy configuration.

5. Download the available output files and verify their structure and content.

Expected results:

• Avalara accepts the invoice without blocking validation errors.

• The generated document follows the supported Italy package configuration.

• The expected download formats are available according to the Italy package definition.

Scenario 2: Credit memo flow

Objective: Verify that a credit memo submitted from Zuora is processed correctly through the Italy package.

High-level steps:

1. Create and post a credit memo in Zuora for an Italy-configured account.

2. Trigger e-invoicing.

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

4. Confirm that references, totals, and response statuses are handled correctly.

Expected results:

• Avalara processes the credit memo using the default Italy template and mapping set.

• The response status and downloadable outputs are available as expected.

Scenario 3: Debit memo flow

Objective: Verify that a debit memo can be submitted and processed correctly for Italy.

High-level steps:

1. Create and post a debit memo in Zuora.

2. Trigger e-invoicing.

3. Verify document creation and validation in Avalara.

4. Review the generated output and returned statuses.

Expected results:

• Avalara accepts the debit memo using the default Italy package.

• Output and response handling are consistent with the configured Italy flow.

Scenario 4: Validation failure and data quality checks

Objective: Use failed submissions to validate data quality rules and mapping completeness before production go-live.

Suggested negative tests:

• missing seller identifier

• missing buyer identifier

• incomplete address information

• missing mandatory mapped fields

• invalid or inconsistent source data between Zuora and Avalara

Expected results:

• Avalara returns clear validation failures.

• The failed fields can be traced back to the corresponding Zuora source fields or template mappings.

• The remediation path is documented for implementation teams.

Scenario 5: Resubmission, resync, regenerate, and download

Objective: Confirm that operational recovery actions work as expected after correcting source data.

High-level steps:

1. Intentionally trigger a validation failure.

2. Correct the source data or mapping issue in Zuora.

3. Re-submit the document.

4. Validate the updated result in Avalara.

5. Test the operational actions used in support workflows, including resync, regenerate, and download.

Expected results:

• The corrected submission is processed successfully.

• Operational runbook steps are validated for the Italy package.

Scenario 6: Activation and environment limitations

Objective: Document environment constraints before UAT signoff.

High-level steps:

1. Attempt to complete the Italy testing flow in the target Avalara environment.

2. Record whether mandate activation requires real IDs or other non-sandbox prerequisites.

3. Document the impact on UAT scope, evidence collection, and release readiness.

Expected results:

• Any activation limitation is explicitly documented.

• Remaining testing gaps are captured along with the reason. Current ticket notes already indicate that end-to-end tests are pending because the mandate is not activated due to the requirement for real IDs.