National E-Invoicing Platform Integration Guide

Every national e-invoicing platform has its own API structure, authentication method, and submission format. While the specifics differ by country, the integration patterns are largely the same and three of the most commonly encountered platforms are AEAT SII, NAV Online Számla, and DGFiP PDP.

Connecting to a national platform is a compliance-first process where every national platform integration requires the same core components: authentication, schema mapping, error handling, and a monitoring layer for submission status. This guide uses Spain, Hungary, and France as working examples; the same approach applies across any national e-invoicing mandate.

Why this is more than an API integration

Most teams approach national e-invoicing processes as a one-time integration task. Hand it to engineering, connect the endpoint, move on. That assumption is where the pain starts.

National platforms are not passive endpoints; they actively validate, reject, and enforce compliance rules on every e-invoice that passes through them. Poland, Italy, and France built these systems to close the VAT gap, not to simplify your workflow. Italy's SDI recovered billions in lost VAT within two years of launch. Poland's KSeF follows the same model. France's phased B2B mandate runs through 2027.

Each platform applies its own schema, requires authentication, authorisation, and security measures that go beyond a standard API call. Governments use these systems to certify every invoice before acceptance, and no e-invoicing solution can facilitate compliant delivery without satisfying those checks first. Get the compliance layer wrong, and your payment doesn't move.

The real cost isn't the integration. It's the rejection loop that follows when tax compliance isn't treated as the foundation from day one.

What KSeF, SDI, and PDP Actually Require

Before a single invoice is submitted, you need to understand what each platform actually demands technically and legally.

KSeF — Poland

KSeF (Krajowy System e-Faktur) is Poland's centralised national e-invoicing system, mandatory for all B2B transactions. Every invoice must be submitted in FA(2) XML schema, authenticated via a qualified electronic signature or authorisation token, and assigned a unique KSeF number before it is legally valid.

SDI — Italy

SDI (Sistema di Interscambio) is Italy's government exchange hub, mandatory for all B2B and B2C domestic transactions since 2019. Every invoice must be in FatturaPA XML format, digitally signed, and accepted by SDI before it legally reaches the buyer.

PDP - France

France's B2B e-invoicing mandate is rolling out in phases through 2027, requiring all businesses to exchange invoices through a certified PDP (Partner Dematerialisation Platform). Factur-X, a hybrid PDF with embedded XML, is the primary supported format. Businesses must also comply with e-reporting obligations for transactions not covered by the B2B mandate.

Each platform behaves differently but all three enforce pre-submission compliance. There are no shortcuts.

Compliance Steps Required Before You Connect

This is the checklist most teams skip. Don't. Each step is a prerequisite; miss one, and your integration fails at the moment it matters most.

1. Register your legal entity with the tax authority
   Italy requires a valid Codice Fiscale and Partita IVA. Poland requires NIP registration and KSeF authorisation setup. France requires SIRET registration and a Chorus Pro account configured before any submission.
2. Obtain the correct authentication credentials
   KSeF uses token-based or certificate-based authentication tied to your NIP. SDI requires a digital signature certificate from an accredited Italian certification authority. Chorus Pro uses OAuth2 API access each credential model is entirely different, and none of them are optional.
3. Map your internal data model to the required schema
   Your ERP or billing system has its own data structure. Every national platform requires a specific XML or hybrid format. This mapping from your internal fields to FA(2), FatturaPA, or Factur-X must be completed and validated before a single invoice is submitted. Missing mandatory fields trigger immediate rejection.
4. Validate tax logic and business rules
   VAT rates, exemption codes, and reporting fields must align precisely with each country's regulations. A tax code that works in your ERP is not automatically correct in KSeF's validation engine.
5. Ensure data protection and GDPR alignment
   Systems handling invoice data across EU jurisdictions must meet GDPR requirements. This means secure data storage, access controls, audit trails, and if using a third-party provider a formal Data Processing Agreement in place before go-live.

Best Practices for Testing and Validation

Testing is where most integrations break not because of bad code, but because teams test too narrowly and too quickly.

• Use real TEST endpoints, not mock data KSeF, SDI, and Chorus Pro all provide sandbox environments that mirror production exactly. Authentic rejection responses only come from real schema validation mock data hides the errors that surface on day one of production
• Test every invoice type, not just the standard one B2B invoices, B2C receipts, credit notes, self-billing, and advance payment invoices each carry different schema requirements; test them all before go-live
• Simulate the full rejection and correction cycle, submission → rejection → correction → resubmission is a real production workflow; if your system can't handle it cleanly in testing, it won't handle it cleanly live
• Validate edge cases missing fields, incorrect tax rates, mismatched buyer and seller data; these are the failures that appear in production, not in clean test scenarios
• Keep your test entity in TEST mode permanently once real entities go live, your test entity stays in TEST mode for regression testing every time a schema updates
• Document every mapping and integration step when the schema version changes (and it will), clear documentation is the difference between a one-hour fix and a three-day incident

According to DDD Invoices' service reliability framework, structured testing and documented integration workflows are the primary factors that determine stable performance and minimise downtime risk after go-live.

Managing Ongoing Changes in National Rules

Regulations evolve, schemas update, new mandatory fields appear, validation logic tightens, and they do it on government timelines, not yours.

Italy updated its FatturaPA schema requirements in 2022. Poland revised KSeF's FA schema ahead of its mandatory rollout. France's PDP certification framework is still actively developing. And sitting above all of this is EU ViDA (VAT in the Digital Age), which will reshape reporting requirements across every member state.

The teams that stay ahead do three things:

Monitor official change logs directly

• Italy: Agenzia delle Entrate — FatturaPA updates
• Poland: Ministerstwo Finansów — KSeF
• France: DGFiP — e-invoicing reform

Separate compliance logic from your product code
If schema mappings and validation rules live inside your core product, every regulatory update becomes an engineering sprint. Externalise compliance logic to a dedicated layer or a platform that maintains it for you so your product stays clean.

Build regulatory change into your SLA expectations
Your compliance provider's SLA should cover regulatory updates, not just uptime. Platforms that absorb government-side schema changes in the backend without requiring reintegration from your developers are the only ones that genuinely scale.

From Fragmented Connections to One Unified Layer

Separate connections for KSeF, SDI, and Chorus Pro feel manageable until platforms update independently, credentials expire on different cycles, and engineering is maintaining compliance instead of building product.

The better architecture is a single API layer that standardises invoice data on your side, then handles country-specific schema conversion, authentication, submission, and status reporting in the background.

This is exactly what DDD Invoices is built for. The unified API accepts standardised JSON, converts it to FA(2), FatturaPA, or Factur-X behind the scenes, authenticates with KSeF, SDI, or Chorus Pro using the correct method per country, and returns status confirmations to your system via webhook or pull API. When national schemas update, 99% of changes are handled in DDD's backend with a minimum of 8 weeks' notice for any breaking API change. Critical incident response starts at 1 hour on Premium support.

FAQs

What is required to connect to national e-invoicing platforms?
You need compliant invoice formats, correct tax logic, authentication credentials, and ERP mapping aligned with each platform's legal requirements.

Why do invoices get rejected by platforms like KSeF or SDI?
Rejections happen due to missing mandatory fields, incorrect tax data, or formats that fail pre-submission validation checks.

Do national e-invoicing rules change frequently?
Yes. Schemas, validation logic, and mandatory fields change regularly. A compliance layer  that absorbs updates automatically removes the need for repeated engineering work each time rules evolve.

Can one API handle KSeF, SDI, and Chorus Pro simultaneously?
Yes. Platforms like DDD Invoices provide a single unified integration that handles schema conversion, certifies compliant submissions, and manages security measures across all three.