Scenario 1: Standard B2B invoice PEPPOL flow

Objective: Confirm that a posted invoice in Zuora results in a valid Norway e-invoice in Avalara and that the document is available in the expected formats.

High-level steps:

1. Create and post an invoice in Zuora for a Norway customer whose seller and buyer e-invoicing fields are fully configured.

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

3. In Avalara, verify that the transaction is created successfully and that the generated document contains the expected seller and buyer identifiers.

4. Download the document in XML, PDF, and UBL_XML, and verify the output.

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

Scenario 2: Credit memo referencing an invoice

Objective: Verify that a credit memo generated in Zuora is submitted successfully to Avalara and represented correctly in the Norway flow.

High-level steps:

1. Create and post a credit memo that references a previously posted invoice.

2. Trigger e-invoicing for the credit memo.

3. In Avalara, confirm that a new document is created for the credit memo and that the references and amounts match the intended adjustment.

Expected results: The credit memo is processed successfully and can be validated and downloaded through Avalara.

Scenario 3: Debit memo flow

Objective: Validate Avalara's handling of debit memos for the Norway PEPPOL configuration.

High-level steps:

1. Create and post a debit memo for a Norway customer with valid e-invoicing identifiers.

2. Trigger e-invoicing in Zuora.

3. In Avalara, verify that the debit memo document is created and that the identifiers and amounts are correct.

Expected results: Avalara accepts and validates the debit memo, and the generated output is available for download.

Scenario 4: Validation failures for identifier and mapping issues

Objective: Use negative testing to validate that missing or incorrect Norway identifiers are surfaced clearly during testing.

Suggested variations:

• Missing or invalid Legal Business Number

• Missing or invalid Tax Register Number

• Missing or invalid E-Invoice Destination Code

• Missing or incorrect schema ID values, including 0192 where required

Expected results: Avalara returns actionable validation feedback so you can correct the source data or mappings in Zuora before production rollout.

Scenario 5: Resubmission after correcting data

Objective: Confirm that corrected transactions can be reprocessed successfully after initial validation failure.

High-level steps:

1. Intentionally submit a transaction with incorrect Norway configuration data.

2. Correct the configuration or source data in Zuora.

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

Expected results: Avalara reflects the corrected transaction state, and your team can follow a repeatable resubmission and reconciliation process.

Scenario 6: Operational recovery and document retrieval

Objective: Validate the operational procedures used after submission, including document retrieval and rerun scenarios.

High-level steps:

1. Submit representative Norway transactions for invoice, credit memo, and debit memo flows.

2. Retrieve the generated outputs from Avalara in the supported formats.

3. Test your operational procedures for regenerate, resync, and download handling in line with your runbook.

Expected results: Your team can successfully retrieve outputs and execute recovery procedures needed for ongoing Norway e-invoicing operations.