How to Map EDI 810/INVOIC to XRechnung

Germany's e-invoicing mandate doesn't ask you to rip out EDI. It asks you to produce one more output format from the invoice data you already generate. If you're running EDI 810 (ANSI X12) or EDIFACT INVOIC flows with German trading partners today, the practical task ahead of January 2027 is a mapping project, not a replatforming project. This walkthrough covers exactly how to take fields from an existing EDI 810/INVOIC flow and populate a compliant XRechnung document, field by field, without abandoning the EDI infrastructure that already works.

What You Need Before You Start

Before touching a mapping tool, get four things in place: an inventory of every EDI 810 or EDIFACT INVOIC flow touching a German counterparty, access to the EN 16931 semantic data model (the Business Term list, not just the XRechnung schema), a translation engine capable of custom transforms (Cleo Integration Cloud, SEEBURGER BIS, Babelway, or your ERP's native e-invoicing module all work), and a willing pilot partner on the German side. You'll also want the KoSIT XRechnung test suite for schema and Schematron validation before anything goes near a live partner.

As of January 2027, Germany will require businesses above the €800,000 turnover threshold to issue invoices in a structured electronic format aligned with the European standard EN 16931. That threshold isn't based on the current year. Under German tax rules, this test evaluates turnover generated in the preceding calendar year, making total 2026 turnover the decisive figure for 2027 compliance obligations. If you clear €800,000 for 2026, you're issuing XRechnung-compliant invoices from day one of 2027. If not, you get until 2028, when full mandatory B2B e-invoicing applies to all businesses, regardless of turnover.

Step 1–3: Confirm Scope, Inventory Flows, and Pick a Target Syntax

1. Confirm your scope. Check your 2026 consolidated turnover against the €800,000 threshold, and separate domestic German B2B partners (in scope for January 2027) from cross-border EU partners, who fall under the later ViDA digital reporting timeline instead.
2. Pull every German EDI flow. List every 810/INVOIC trading partner connection that touches a German legal entity, and don't stop at purchase-to-pay invoices. Freight and logistics invoicing between German-based carriers and shippers is still domestic B2B, so a German 3PL invoicing a German manufacturer falls under the same rule once either party crosses the threshold.
3. Pick your target syntax. XRechnung isn't a single fixed schema; it supports two underlying syntaxes. XRechnung 3.0 uses UBL 2.1 / CII syntax for German public sector invoicing. Most commercial mapping tools default to UBL 2.1, and that's the sensible default unless your ERP's native CII support is already mature. ZUGFeRD is the other accepted route for most profiles.

Step 4–6: Build the Field-Level Mapping

This is where the actual EDI to XRechnung mapping work happens, and where most teams underestimate the effort. EN 16931 defines around 150 Business Terms; EDI 810 and EDIFACT INVOIC use positional segments that don't map one-to-one.

1. Map core segments to Business Terms using the table above as a starting structure, then expand it line by line against your own partner-specific EDI implementation guide, since no two trading partners use SAC or ALC segments identically.
2. Solve the VAT category mismatch. EDI tax codes almost never align cleanly with EN 16931's VAT category codes (BT-151 and friends). Don't let your mapping tool apply a default; build an explicit cross-reference table between your EDI tax code list and the EN 16931 category codes, and have someone from tax or finance sign off on it before the first test invoice goes out.
3. Decide on architecture: replace or run parallel. Running EDI and XRechnung in parallel is the lower-risk path. Keep EDI 810/INVOIC as your internal canonical invoice format for ERP and warehouse processes, and add a transformation layer that emits an XRechnung document only for the outbound compliance copy. This also happens to be what the law anticipates: businesses with turnover at or below €800,000 and EDI users not yet EN 16931 compliant may still use other formats during the extended transition.

Step 7–9: Validate, Transmit, and Confirm Delivery

A mapping that looks correct on screen can still fail validation. Run every converted document through a validator before it ever reaches a partner.

1. Validate against KoSIT rules. The KoSIT validator checks XRechnung in UBL (Invoice and CreditNote) and in CII against the same EN 16931 and XRechnung rules. If you're issuing B2G invoices alongside B2B ones, this step also catches missing fields like the Leitweg-ID, since XRechnung's BR-DE rules specifically check for the Leitweg-ID for the German public sector, along with payment means and buyer reference.
2. Pick a transmission channel. Germany doesn't run a central clearance platform for domestic B2B exchange. Exchange is decentralised: Germany does not use a central government clearance portal for domestic B2B trade; invoices are exchanged directly between trading partners via open networks like Peppol, secure email, or direct platform integrations. Peppol via AS4 is the most interoperable option if your partner already receives Peppol traffic, and you can use the Peppol network for e-invoicing in Germany, and it's already mandatory for B2G invoicing.
3. Confirm the pipeline actually works. A clean KoSIT validation pass plus a Peppol Message Level Response showing acceptance, or a direct partner acknowledgment on a bilateral channel, is your end-to-end confirmation. Don't treat schema validation alone as proof; schema-valid documents still fail Schematron business rules regularly.

Failure Mode: When the Validator Rejects a Converted Invoice

The most common rejection isn't a schema error. It's a schema-valid, Schematron-invalid document, usually caused by an incomplete VAT breakdown or a totals mismatch inherited from loosely-typed EDI fields. One concrete example from real validator output: BR-CO-10, where the sum of line net amounts (BT-106) does not match the individual lines (BT-131). EDI flows tolerate small rounding drift that nobody ever reconciles because the ERP absorbs it silently. EN 16931's calculation checks don't.

The fix isn't more validation after transmission, it's a pre-validation reconciliation step inside your mapping tool that flags any invoice missing a required field or failing a sum check before it leaves your system. Catching a missing BT-31/VAT pairing in your own pipeline costs you a mapping fix. Catching it after a partner rejection costs you a late payment and an awkward phone call.

None of this requires a big-bang cutover. EDI arrangements that do not yet meet EN 16931 are permitted for everyone until the end of 2027. Use that window to run the hybrid pipeline in production before the full 2028 floor applies to every business, regardless of turnover.

Where This Intersects With Transport and Carrier Invoicing

Freight invoices get overlooked in most e-invoicing planning because they sit outside the standard purchase-to-pay flow, but they're domestic B2B invoices like any other. A German carrier invoicing a German shipper for linehaul or warehousing services falls under the same rule once either side crosses the turnover threshold. This matters for logistics operations working with DB Schenker, DHL Freight, or regional German 3PLs, where the invoice often arrives through a freight audit process rather than a standard AP pipeline.

Multi-carrier TMS and freight visibility platforms are usually where carrier invoice reconciliation actually happens day to day. Vendors like MercuryGate, Descartes, Transporeon, Alpega, and connectivity-focused platforms such as Cargoson sit between shippers and dozens of carriers, and that's exactly the layer where an XRechnung gap would surface first. If you're running freight invoices through one of these platforms, ask the vendor directly whether XRechnung output is on their German compliance roadmap, rather than assuming it inherits from your ERP's invoicing module.

Quick Reference Checklist

• 2026 turnover checked against the €800,000 threshold, scope of in-scope German partners confirmed
• Every EDI 810/INVOIC field mapped to its EN 16931 Business Term, including freight and logistics invoice flows
• VAT code cross-reference table built and signed off by finance, not left to default mapping
• Test invoices passing KoSIT Schematron validation with no BR-DE or BR-CO rule failures
• Transmission channel live, whether Peppol AS4 or bilateral, with a confirmed partner-side acknowledgment
• Pilot partner has received and accepted at least one full invoice cycle end to end

Start with one pilot partner and one invoice type. Get a single EDI 810 or INVOIC flow converted, validated, and accepted before you scale the mapping across your full German partner list. The teams that struggle with this deadline aren't the ones with complex EDI estates, they're the ones who waited until Q4 2026 to find out their VAT code mapping didn't hold up under Schematron validation.