E-Invoice Testing Checklist: 15 Checks Before You Go Live

You've built the integration. The e-invoicing module is configured. Test invoices look correct. You're ready to go live.

Almost.

The gap between "it works in testing" and "it works in production" is where e-invoicing projects stumble. Production traffic brings edge cases that sample testing misses: zero-VAT invoices, credit notes, multi-currency transactions, cross-border deliveries with country-specific CIUS rules.

This checklist covers 15 checks that have each caught at least one real production issue. Three groups: format and schema, business rules, and country and network.

Format & Schema (Checks 1-5)

Schema failures are the most basic rejection type — if these don't pass, business rule checks never run.

1. Validate Against the Correct Schema Version

This sounds elementary, but it catches people. If you're targeting Peppol BIS 3.0, your invoices must validate against UBL 2.1 Invoice or CreditNote schemas. If you're targeting XRechnung, you need the correct XRechnung-specific schema artifacts. If you're generating ZUGFeRD or Factur-X, you need the CII (Cross-Industry Invoice) schema, not UBL.

Why it matters: Validating against the wrong schema misses real errors or flags false positives. Both create false confidence.

How to check: Upload a sample invoice to the validator and confirm the detected format matches your intended target. If it detects something different, your template is using the wrong schema or namespace.

2. Verify Your CustomizationID Matches Your Target Network

The cbc:CustomizationID element (BT-24) declares which specification profile your invoice conforms to. Every receiving system uses this value to determine which validation rules to apply. If it's wrong, the receiver either rejects the invoice outright or applies the wrong rule set.

For Peppol BIS 3.0:

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0

For XRechnung (check current version):

urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0

Why it matters: A missing or incorrect CustomizationID triggers BR-01. An outdated version string causes silent rejections at receivers that have updated their validation artifacts — the invoice content is correct, but the header declares the wrong specification.

How to check: Extract the CustomizationID from your XML and compare it character-by-character to the current required value. Check the ProfileID too.

3. Check All Mandatory Elements Are Present (Not Just Filled, but Correct)

There's a difference between "the element exists in the XML" and "the element contains a valid value." An empty <cbc:DocumentCurrencyCode/> element is present but not valid. A <cbc:RegistrationName> </cbc:RegistrationName> element with only whitespace is present but not useful.

Why it matters: Some ERP templates include mandatory elements but leave them empty when source data is missing. Schema validation passes (element exists), but business rule validation fails because the value is empty.

How to check: Run your test invoice through the validator checking all four layers. Business rules catch "present but empty" cases that schema validation misses.

4. Validate Date Formats (ISO 8601, Not Locale-Dependent)

Every date in your invoice XML must be in YYYY-MM-DD format. Not DD/MM/YYYY. Not MM-DD-YYYY. Not June 30, 2026. ISO 8601, full stop.

Why it matters: Date format errors produce cvc-datatype-valid.1.2.1 failures at the schema level. European ERPs with DD.MM.YYYY locale settings commonly inherit the wrong format in XML output.

How to check: Open the raw XML and inspect all date fields: issue date (BT-2), due date (BT-9), delivery date (BT-72). Don't rely on the ERP's display — check the actual XML.

5. Verify Currency Codes Are ISO 4217 Uppercase

The document currency code (BT-5) must be a valid three-letter ISO 4217 code in uppercase. EUR, not eur. GBP, not Gbp. Not Euro. Not a currency symbol.

Why it matters: BR-05 checks presence and validity of the currency code. If the value doesn't match the ISO 4217 codelist, validation fails.

How to check: Generate invoices in every currency your business uses and verify each contains the correct ISO code. Multi-currency scenarios are particularly error-prone.

Business Rules (Checks 6-10)

These checks test the business logic that EN 16931 enforces — scenarios that standard sample invoices often miss.

6. Test with Invoices That Have 0% VAT

Zero-VAT invoices trip up more e-invoicing implementations than any other edge case. There are multiple reasons why VAT might be zero — reverse charge, intra-community supply, tax-exempt services, export outside the EU — and each one requires different handling in the invoice XML.

Why it matters: EN 16931 requires a tax exemption reason code in BT-121 when VAT is zero. ERPs handle the accounting correctly but often don't populate the reason code in XML.

How to check: Generate at least three test invoices: reverse charge, intra-community exemption, and domestic VAT-exempt supply. Validate each one. Skip this and you'll discover the issue when a real reverse-charge invoice gets rejected.

7. Verify Calculation Rules (Line Totals -> Tax Totals -> Payable Amount)

EN 16931 enforces a specific calculation chain. Each invoice line has a net amount. Line net amounts sum to the invoice subtotal. Tax is calculated from the taxable amounts per tax category. The final payable amount is derived from the sum with VAT minus any prepayments plus any rounding adjustment.

Why it matters: ERPs that calculate totals independently can produce values that are mathematically correct but don't match the EN 16931 calculation sequence. A one-cent rounding difference fails the BR-CO-* cross-field rules.

How to check: Create a test invoice with multiple lines and mixed VAT rates (standard, reduced, zero on the same invoice). The validator flags any calculation mismatches with the specific BR-CO rule that failed.

8. Test Credit Notes, Not Just Invoices

Credit notes have different XML requirements. The document type code is different (381 instead of 380). Some elements that are mandatory on invoices are optional on credit notes, and vice versa. The calculation logic may differ — negative amounts, references to the original invoice being credited.

How to check: Generate a credit note referencing an existing invoice. Validate it separately. Pay attention to UBL-CR errors (elements present in Invoice but not allowed in CreditNote) and check that the document type code is correct.

9. Verify Party Identifiers (GLN, Peppol ID, VAT Number Formats)

Peppol requires specific identifier schemes for seller and buyer party identification. The scheme ID and value format must match. A Belgian enterprise number uses scheme 0208. A Dutch KVK number uses scheme 0106. A German VAT number uses scheme 9930. A GLN uses 0088.

Why it matters: Invalid identifiers cause routing failures (Peppol can't find the receiver) and validation failures (format doesn't match the declared scheme). A structurally perfect invoice becomes undeliverable.

How to check: Verify the scheme ID and value format for both seller and buyer identifiers. Check that the Peppol endpoint identifier matches the recipient's registered Peppol ID via the SMP directory lookup.

10. Test with Real Recipient Identifiers (Not Test Endpoints)

Using test Peppol IDs during development is standard practice. But test endpoints have different validation behavior than production endpoints. Some test environments are more lenient. Others enforce rules that the production network doesn't. Testing against a test endpoint tells you your invoice works in the test environment — nothing more.

Why it matters: Production Access Points may enforce additional rules, use different Schematron artifact versions, or apply country-specific validation that test environments skip. An invoice that passes test validation and fails production validation is a go-live blocker.

How to check: Before going live, send at least one validated test invoice to a real production recipient (coordinate with a trusted customer or trading partner). Verify the full round trip: send, delivery confirmation (positive MLR), and receipt by the buyer's system.

Country & Network (Checks 11-15)

These checks verify that your invoices meet country-specific requirements and work end-to-end through the Peppol network.

11. Check Country-Specific CIUS Rules

Each EU country can define additional validation rules (a CIUS — Core Invoice Usage Specification) on top of EN 16931. These rules add requirements that the base standard doesn't cover.

Germany (BR-DE-*): Requires a Leitweg-ID in BT-10 for public sector invoices. Requires specific payment means codes. Mandates the seller's email address.

Netherlands (SI-UBL): Requires specific ordering of certain elements. Has additional rules for Dutch government invoices.

Belgium (BEvCIUS): Requires the KBO/BCE enterprise number with scheme ID 0208. Has additional rules for B2B mandated invoices since January 2026.

Why it matters: An invoice that passes all EN 16931 and Peppol BIS rules can still fail at the country level. If you're sending invoices to receivers in multiple countries, you need to test against each destination country's CIUS rules.

How to check: Validate test invoices with the destination country's specific rule set. The validator applies country-specific rules automatically based on the buyer's country code and identifier scheme. Check the country-specific errors for details on each country's additional requirements.

12. Verify Peppol Participant Lookup Works for Your Recipients

Before you can send an invoice over Peppol, your Access Point needs to find the receiver's Access Point in the Peppol network directory. This lookup uses the receiver's Peppol Participant ID (a combination of scheme ID and identifier value).

Why it matters: If the lookup fails — because the recipient isn't registered on Peppol, the identifier is wrong, or the SMP entry is misconfigured — the invoice can't be delivered. You won't get an MLR rejection because the invoice never enters the network. Instead, you'll get a delivery failure from your Access Point.

How to check: For each major recipient you plan to invoice, verify their Peppol registration. Your Access Point typically provides a lookup tool, or you can check the Peppol directory directly. Confirm the participant ID matches what's in your ERP's customer record.

13. Test with the Receiving Access Point's Validation (Not Just Your Own)

Your Access Point validates invoices before sending them. But the receiving Access Point (the buyer's AP) also validates incoming invoices. These two APs may run different versions of the validation artifacts, enforce different severity levels, or apply additional custom rules.

Why it matters: An invoice that passes your AP's validation might fail at the receiver's AP, resulting in an MLR rejection. This is common during specification transition periods when APs update artifacts on different schedules.

How to check: Validate independently using a tool that runs the latest published validation artifacts. Don't rely solely on your own AP's validation. Our validator always runs current production artifacts.

14. Verify Evidence Pack Generation If Using Auto-Remediation

If your validation pipeline includes auto-remediation (automatically fixing structural issues like removing disallowed elements, correcting namespace prefixes, or normalizing date formats), verify that the evidence trail is complete.

Why it matters: Auto-remediation changes the invoice XML. You need a complete record: original invoice, validation report, remediated invoice, and change log. Without this, you have a compliance gap.

How to check: Run a test invoice through your full pipeline with remediation enabled. Verify you can access the original XML, the applied fixes, and the final validated XML. See the validation pipeline guide for architecture details.

15. Run a Full Batch Through Validation

Single-invoice testing is necessary but not sufficient. Production traffic includes batch processing, concurrency, and variety. A batch of 100 invoices from different customers, with different currencies, different VAT scenarios, and different destination countries will surface issues that single-invoice testing misses.

Why it matters: Batch-specific issues include: encoding problems with non-ASCII characters (umlauts, diacritics in buyer names), data-dependent errors in specific customer records, and rate limiting or timeout handling.

How to check: Export a representative batch from your ERP — a real cross-section, not hand-picked samples. Validate every one. Review aggregate results: error distribution, patterns by customer or template. Fix the patterns, not individual invoices.

After the Checklist

If all 15 checks pass, you're ready. But keep the pre-send validation gate running permanently — not just as a go-live test, but as continuous compliance. The teams that go live smoothly are the ones that validate before sending, not after rejection.

FAQ

How many test invoices should I validate before going live?

There's no magic number, but coverage matters more than count. You need at least: one standard invoice with VAT, one with zero-rate VAT, one credit note, one multi-line invoice with mixed VAT rates, and one invoice per destination country you serve. For most businesses, that's 10-20 test invoices. The batch test (check 15) should use your actual production data — the more invoices, the more edge cases you catch.

Should I validate in my test environment or production environment?

Both, but they answer different questions. Test environment validation confirms your template configuration works. Production environment validation confirms your real master data (customer records, company details, currency settings) produces valid invoices. Many go-live issues come from data differences between test and production — missing customer data, different company profiles.

What if I find errors during the checklist that I can't fix before my go-live date?

Prioritize by impact. Schema errors and missing mandatory fields (checks 1-5) are blockers — every invoice will fail. Business rule errors in specific scenarios (checks 6-8) affect a subset of invoices — you can go live for the invoices that pass and handle the edge cases manually. Country-specific errors (check 11) only affect invoices to that country. Understand which invoices fail and decide whether to delay go-live or go live with a known exception list.

Do I need to repeat this checklist after specification updates?

Yes, at least the relevant checks. When Peppol releases new validation artifacts (typically twice a year) or a country updates its CIUS rules, you should re-validate a representative batch. The CustomizationID check (check 2) and country CIUS check (check 11) are the most update-sensitive. Keep your validator up to date — or use a hosted validator that always runs the current artifacts.

Can automated testing replace this checklist?

It can automate most of it. Checks 1-9 and 11-12 are automatable through a validation API integrated into your CI/CD pipeline or invoice processing workflow. Checks 10, 13, and 14 require some manual coordination (real recipient testing, cross-AP validation). Check 15 is automatable once you have a batch validation workflow. The validation pipeline guide covers the architecture for continuous automated validation.