EU Invoices in Salesforce: ZUGFeRD & Factur-X Without Conga

The EU electronic invoice clock is ticking

Across the EU, B2G invoicing already requires structured electronic invoices that meet EN 16931. B2B mandates are tightening (Germany 2025–2028 transition, France's Chorus Pro expansion, Belgium 2026). Salesforce-driven invoicing that still ships plain PDFs will face rejections and late-payment risk.

The good news: you do not need to leave Salesforce to comply. The right tool produces ZUGFeRD/Factur-X straight from Opportunity or custom invoice objects.

What hybrid PDF/XML actually means

• PDF/A-3 wrapper readable by humans.
• EN 16931-compliant XML (Cross-Industry Invoice) embedded as attachment.
• Profile selection: BASIC, EN16931, EXTENDED—pick the minimum your buyer accepts.
• Schematron validation before the file leaves your org.

Salesforce-specific mapping challenges

1. Account → Buyer party. VAT, tax registration, billing address, country code—every field must match the EN 16931 schema.
2. Currency. Use Opportunity's CurrencyIsoCode and respect the buyer's invoicing currency rules.
3. Line items. Map OpportunityLineItem to BG-25 InvoiceLine; carry net amount, tax category, VAT rate, and unit code.
4. Allowances and charges. Discounts on Opportunity should land as document-level allowances, not silently embedded in price.
5. Payment terms. Map to BT-9, BT-10 (due date, payment reference); avoid free-text drift.

Country specifics for Salesforce orgs

• Germany (XRechnung): federal buyers expect Peppol BIS-aligned files; ZUGFeRD 2.x EN 16931 covers most non-federal.
• France (Chorus Pro): Factur-X EN 16931 plus buyer routing code (SIRET) in BT-49.
• Italy (FatturaPA): separate XML schema; consider a converter at the edge driven by your EN 16931 source.
• Belgium and Poland: Peppol BIS Billing 3.0 with country-specific extensions.

Validation is non-negotiable

The right flow validates the XML against Schematron before attaching to Salesforce. Catching errors at generation time beats finding them when Chorus Pro rejects the file two days later. Persist the validation report next to the PDF for audit.

Where most Apex/Conga builds fail

• Custom Apex builds the XML by string concatenation—breaks on the first non-ASCII character.
• Conga or Word merge produces only the PDF, missing the XML attachment.
• Hardcoded currency or country fails the first time a deal crosses borders.
• No Schematron means the file looks right and silently fails buyer ingestion.

Operational checklist

1. Pick the minimum EN 16931 profile your top 5 buyers accept.
2. Map every Opportunity/Invoice field to a BT-/BG- code in EN 16931.
3. Validate every generated file before attaching to Salesforce.
4. Store the validation report and template version per file.
5. Run a 50-invoice batch through a test buyer endpoint before go-live.

Mapping Salesforce invoice objects to EN 16931 without custom Apex

Most orgs store bill-to data on Account, line economics on OpportunityLineItem or custom Invoice Line objects, and tax in managed packages. The generator must read that graph once per render—not copy fields into a staging Sheet that drifts from Salesforce truth.

Validate XML before attach: a rejected hybrid invoice on a closed-won Opportunity is harder to unwind than a render error caught at click time.

Salesforce → BT code reference

Go-live validation sequence

1. Render test invoice from sandbox Opportunity with real VAT test numbers.
2. Run Schematron locally; fix mapping before UAT sign-off.
3. Submit one file to buyer sandbox (Chorus Pro, Peppol test AP).
4. Attach validation report PDF to the Invoice record in Salesforce.
5. Enable Flow only after three consecutive green sandbox submissions.

Example: DE public-sector Opportunity

Opportunity closes with buyer requiring XRechnung-compatible ZUGFeRD. User clicks Generate Invoice; engine maps Account SIRET equivalent, embeds CII XML in PDF/A-3, validates BT-10 buyer reference populated from custom field. Schematron passes; file attaches to Opportunity Files with log ID. AP clerk ingests on first try—no email thread with "please resend XML only."

Peppol routing from Salesforce billing data

Public-sector buyers require endpoint IDs in structured fields—not notes on the Account. Map Peppol participant ID to a validated custom field; block generate when format check fails.

Keep a buyer registry object synced from procurement portals so sales does not paste obsolete routing codes during Opportunity close frenzy at quarter end.

Enable validation error emails to billing ops with BT code and Opportunity link—developers should not be the first line when Chorus Pro rejects BT-48 on a Friday afternoon.

Align billing ops and Salesforce admins on a single invoice numbering object—duplicate sequences between custom Invoice__c and legacy ERP imports create rejections that look like generator bugs but are data collisions.

Document automation earns trust when ops owns the pipeline: weekly batch reviews, mapping change control, and a single owner who can explain every failed row to finance without opening three tools. Treat the generator like payroll—silent success, loud failures, zero mystery duplicates in numbering or filenames.

Where DocForge for Salesforce fits

DocForge for Salesforce embeds ZUGFeRD and Factur-X XML in every invoice generated from Opportunity or custom objects, validates against Schematron, and attaches the PDF with the validation report. Sign in and run your first compliant batch in a sandbox.