Scenario 1: Standard B2B invoice clearance flow

Objective: Confirm that a posted France invoice in Zuora results in a valid France e-invoice payload in Avalara for the France Clearance process.

High-level steps:

1. Generate and post an invoice in Zuora for a France customer whose seller and buyer data are configured with the required France identifiers.

2. Trigger e-invoicing so the invoice is submitted to Avalara through the France business region configured for Clearance.

3. In Avalara, verify that the invoice is processed under the France company and mandate configuration.

4. Review the generated document and confirm that the seller and buyer identifiers match the France configuration values used in Zuora.

5. Download the supported output formats and confirm the payload structure matches expectations.

Expected results:

• Avalara validates the France invoice payload using the configured France identifiers and mappings.

• The France document is available in the configured download formats after successful processing.

Scenario 2: Credit Memo as a correction flow

Objective: Verify that a credit memo generated in Zuora is handled as a France correction document in Avalara.

High-level steps:

1. Create and post a credit memo for an invoice that was previously submitted for France e-invoicing.

2. Trigger e-invoicing for the credit memo and verify the document appears in Avalara as a new France e-invoice transaction.

3. Confirm that the credit memo references the original invoice according to your mapping design.

Expected results:

• Avalara treats the credit memo as a correction to the original invoice rather than as an unrelated standalone document.

• The credit memo uses the same France-specific identifier rules as the original invoice.

Scenario 3: Debit Memo flow

Objective: Verify that France debit memos can be generated and processed through the France package in Avalara.

High-level steps:

1. Create and post a debit memo in Zuora for the same France configuration used in the invoice flow.

2. Trigger e-invoicing and confirm that the France debit memo payload is generated and submitted to Avalara.

3. Validate the debit memo document data and supported downloads in Avalara.

Expected results:

• Avalara processes the debit memo as a supported France billing document.

• The generated document remains consistent with the configured France seller and buyer master data.

Scenario 4: Validation failures and data quality checks

Objective: Identify how Avalara surfaces France validation failures when France-specific identifiers or mappings are incomplete or incorrect.

Suggested negative tests:

• Use an invalid or missing SIREN number.

• Use an invalid or missing FR-prefixed SIRET number.

• Use an invalid or missing Addressing Line Identifier or incorrect schema IDs.

• Submit documents with inconsistent seller and buyer identifiers between Zuora and Avalara.

Expected results:

• Avalara identifies the validation failure clearly so you can refine the France mappings or master data.

• Your team can distinguish template issues, configuration issues, and source-data issues during France onboarding.

Scenario 5: Resubmission, resync, and regeneration

Objective: Confirm the operational recovery flow for France after correcting failed data or mappings.

High-level steps:

1. Cause a France validation failure by using one of the negative test cases.

2. Correct the underlying France data or template mapping in Zuora.

3. Use Regenerate E-Invoice and Resync E-Invoice Status as appropriate.

4. Download the corrected file and compare it with the failed version.

Expected results:

• France resubmission follows the same operational pattern expected for pre-integrated Avalara countries.

• Corrected data is reflected in the regenerated France payload and final status flow.

Scenario 6: Cancellation and correction limitations

Objective: Document the supported France correction pattern and the current product limitation for automated cancellation.

High-level steps:

1. Start from a posted France invoice that needs to be canceled or corrected.

2. In Zuora, create a credit memo or other corrective document instead of expecting an automated cancellation API call to Avalara.

3. Submit the corrective document and verify that the correction pattern is documented in your France runbook.

Expected results:

• Your team uses the correction-document approach for France instead of relying on automated cancellation from Zuora to Avalara.

• The France documentation and operational guidance clearly call out this limitation until product behavior changes.

Scenario 7: Buyer-driven business status synchronization

Objective: Confirm that business status updates received through Avalara/CDAR are synchronized to the corresponding e-invoice record in Zuora.

High-level steps:

• Start with a France e-invoice that has already been generated and submitted successfully.

• Simulate or receive a buyer-driven business status update through Avalara/CDAR.

• Verify that the corresponding E-Invoice Business Status in Zuora is updated automatically.

• Review the audit trail for the status change.

Expected results:

• Zuora reflects the updated business status received through Avalara/CDAR.

• The status history shows the previous status, new status, source, and timestamp.

Scenario 8: Seller-driven manual business status update

Objective: Verify that a seller can manually update the E-Invoice Business Status from Zuora for a supported France e-invoicing flow.

High-level steps:

• Start with a posted France invoice that has already entered the e-invoicing lifecycle.

• Perform a manual business status update from Zuora.

• Save the change and review the updated status on the e-invoice record.

• Check the audit timeline for the update entry.

Expected results:

• The manual update is applied successfully for the supported status transition.

• The audit timeline records the actor, previous status, new status, and timestamp.

Scenario 9: Payment Collected update after external payment

Objective: Verify that the seller can explicitly set the business status to Paid / Payment Collected when payment is collected externally.

High-level steps:

• Use a France invoice for which payment was collected outside the standard Avalara-triggered flow.

• Update the E-Invoice Business Status in Zuora to Paid / Payment Collected.

• Validate the saved status and review the corresponding audit entry.

Expected results:

• The e-invoice record shows Paid / Payment Collected after the update.

• The update is historically traceable in the audit log.

Scenario 10: Re-sync protection for successful statuses

Objective: Confirm that re-sync or reset operations do not silently overwrite a successful business status.

High-level steps:

• Move a France e-invoice to a successful business status.

• Trigger a re-sync or reset operation as part of an operational recovery flow.

• Compare the status before and after the operation.

• Review the audit history for any related changes.

Expected results:

• A successful business status is not silently overwritten during re-sync or reset.

• Any resulting status change is explicit and traceable in the audit history.