For most enterprises, choosing an Approved Platform (Plateforme Agréée, or PA) is the easy part. Making it work with the systems that actually produce and receive invoices is harder. If your invoices are created in SAP or another ERP, Approved Platform SAP integration decides whether compliance runs quietly in the background or turns into a manual, error-prone process for finance and IT. This guide explains how the integration works, which approaches exist, and what to check before you commit.
What Integrating with an Approved Platform Actually Means
For domestic B2B transactions within the scope of the French reform, invoices pass through a registered PA. It validates the document, identifies the recipient’s platform and electronic invoicing address through the public directory, routes the invoice to the recipient’s platform, and reports the required data to the tax administration. The public directory supports routing; it is not an invoice recipient.
In practice, the integration has to handle four flows:
- Outbound invoices: your ERP produces the invoice data, and the PA or connected solution converts it into a compliant format (Factur-X, UBL or CII), validates it against EN 16931 and the applicable French rules, and transmits it.
- Inbound invoices: the PA receives structured invoices addressed to you and passes them to your ERP for posting and approval.
- Status feedback: the PA returns applicable lifecycle statuses and rejection reasons so users can see what happened to each document. Align the SAP status mapping with the French lifecycle requirements.
- E-reporting: applicable transaction data for B2C and cross-border flows, and payment data where required, is reported through the platform separately from invoice exchange.
A solid integration covers all four. Many projects focus only on sending and discover the rest late.
Three Ways to Connect SAP to an Approved Platform
There is no single correct pattern. The right one depends on your SAP landscape, your IT capacity and your timeline.
1. Native SAP add-on
An SAP e-invoicing add-on is installed inside supported SAP ECC or S/4HANA environments through a transport and configuration project. Invoice generation, format mapping, transmission and status updates are managed from the SAP interface, so finance users keep working in the screens they already know. Confirm compatibility with your SAP edition and deployment model before choosing this route.
Best for: organisations with high invoice volumes, several company codes, or a preference for keeping operations inside SAP. Trade-off: it requires an installation and configuration project on the SAP side.
2. API integration
With an electronic invoicing API, your own SAP team or SAP partner builds the connection. SAP generates the invoice data and calls the platform’s API, and statuses come back through callbacks or can be pulled on demand. It can run as a button in SAP or as an automatic trigger on billing.
Best for: teams with SAP development capacity who want full control over the process. Trade-off: there is no packaged screen inside SAP, so the send function, any invoice preview and the display of statuses in SAP are part of your own development. Effort therefore depends mainly on your side.
3. EDI or file-based exchange (IDoc, SFTP)
SAP exports invoice data as IDoc or other agreed file formats, which are exchanged with the platform through an interface such as SFTP or existing middleware. The platform converts and transmits the invoices. IDoc defines the SAP message format; SFTP is one possible transport method. Mapping, export configuration and monitoring still need to be designed.
Best for: landscapes that already use IDoc or file interfaces, or where changing SAP is difficult. Trade-off: file-based implementations often use batch-style flows, and status feedback to SAP needs additional handling.
Some organisations combine these patterns, for example an add-on for the main entity and a standalone e-invoicing portal for small subsidiaries without ERP integration.
Factur-X and SAP: What to Know
Factur-X is a PDF with embedded structured XML, which makes it useful for teams moving away from PDF invoicing. For Factur-X SAP projects, one point causes confusion: the printed invoice from an SAP form is not automatically a Factur-X invoice. A compliant file needs CII XML embedded in a PDF/A-3 document, with consistent readable and structured data, and validation against the required profile and rules.
It can be cleaner to let the platform or add-on produce the Factur-X file from the invoice data SAP provides, rather than implementing the full hybrid format in output forms. Your existing layout may be reusable, but PDF/A-3 conversion, XML embedding and validation still need testing. Agree which format updates the provider maintains.
What a Good Electronic Invoicing API Should Offer
If you take the API route, evaluate the API as seriously as the platform behind it. Ask for:
- A sandbox that lets your developers build and test without touching production or registering anything live.
- Clear documentation with sample payloads for outbound and inbound documents.
- Secure authentication, such as API keys or tokens, with suitable access controls and credential management.
- Real-time status callbacks (webhooks), so SAP does not need to poll for the result of every invoice.
- Useful validation errors that tell your team exactly which field failed and why.
- Coverage beyond France, if you also invoice in other countries, so you can reuse the integration architecture while applying local requirements.
Beyond SAP: The ERP Connector Question
Not every group runs on SAP alone. A subsidiary may use Dynamics 365, Oracle, Sage or Odoo. When assessing an ERP connector for an Approved Platform, check whether the provider offers ready connectors or only an API, who builds and maintains the mapping, and whether one platform can serve all entities under a single contract. Fragmented integrations multiply maintenance costs every time a format or regulation changes.
Questions IT and SAP Teams Should Ask Before Choosing
- Is the provider a registered Plateforme Agréée, verifiable on the official DGFiP list?
- Which integration patterns are supported (add-on, API, EDI, portal), and which one fits our SAP version and deployment (ECC or S/4HANA)?
- Who owns the SAP-side work, and what does it cost in internal days?
- How are inbound invoices posted into SAP (MIRO, FB60, workflow)?
- How do statuses and rejection reasons get back to users?
- Are regulatory updates included, or does each change trigger a new project?
- How are e-reporting and archiving handled?
A Realistic Project Outline
Whatever pattern you choose, projects follow a similar path: scoping and access, design and field mapping, build and configuration, testing with the platform’s test environment, user acceptance, then go-live and monitoring. Starting scoping before your deadline pressure peaks leaves time for testing, which is where most delays appear.
Choosing the Right Approach
If you want the least change for SAP users and have many entities, a native add-on usually fits. If you have strong SAP developers and want to own the process, an API is flexible. If your SAP landscape is stable and already runs on IDoc or files, an EDI approach can reuse those interfaces. If an entity has no ERP link at all, a portal can be live quickly while the larger integration is prepared.
Explore the Melasoft SAP e-invoicing Add-On or the Docnova e-invoicing portal. To discuss the integration pattern for your landscape, book a free 30-minute consultation.