One Certified Platform Is a Bottleneck the Moment You Have More Than One Entity
A single certified platform (a Plateforme Agréée) works fine for a company with one legal entity. For a group with more than one, betting the whole group on a single platform’s connector locks every subsidiary into that platform’s pricing tier, its coverage, and its release schedule — and nobody selling you a connector has a reason to point that out before you sign.
Why does platform choice change once a group has more than one entity?
Certified-platform pricing is typically per invoice and degressive with volume, so consolidating a group’s volume onto one platform can improve the price band. But entities are rarely equal: one subsidiary doing 200 invoices a month with consumer sales has a different e-reporting profile than a B2B entity doing 20,000. We map the six group-level decisions this creates in a companion article; this one stays on a single decision — the connector itself — and what “locked in” costs in practice, not in theory.
What does “locked into a connector” actually mean, technically?
Most e-invoicing connectors are point integrations: the purchase-draft logic — matching, VAT handling, status tracking — is written directly against one platform’s API contract and JSON shape. That is not a vendor-relationship problem you can renegotiate; it is code. The platform’s field names, its authentication flow, its pagination model are woven into the same routines that create the purchase draft. Changing platform does not mean signing a new contract — it means finding and unwinding every place the old platform’s format leaked into the business logic, then rebuilding it against the new one.
That is the actual bottleneck, and it is invisible until a group tries to add a second platform under deadline pressure — which is exactly when a reform with a fixed date forces the issue.
How is the Business Central connector built to avoid that?
We built the platform connection as an interface: a fixed contract — retrieve new e-documents from the platform, check a document’s status, send a status back — that any certified platform implementation has to fulfil. The purchase-draft logic in Business Central talks only to that contract. It never calls a platform’s API directly, never parses that platform’s specific JSON shape inside the matching or VAT routines.
Two implementations exist today, for SuperPDP and Tréso2. Adding a third certified platform means writing a new implementation of the same contract — a self-contained unit of work — not touching the purchase-draft logic, the AFNOR status handling, or anything a user already relies on. FacturaLink is where we built this: the connector layer between Business Central and a certified platform, built to that interface on purpose.
How does the connector actually stay synchronised with a platform?
Certified platforms like SuperPDP do not push events to Business Central — there is no webhook. The connector polls on a schedule (a Job Queue entry, every 15 to 30 minutes) and asks the platform for anything new since the last check, using a strictly increasing identifier as the cursor. That is a deliberate trade-off: polling is slower than a push model by definition, but it means Business Central never has to expose an inbound endpoint on the internet, and a missed poll cycle does not lose a document — the next cycle simply picks up from the same cursor.
Authentication follows the same discipline. The connector authenticates with OAuth 2.1 using client credentials — no user is involved — and caches the resulting token for its full thirty-minute lifetime instead of requesting a new one on every call. Both choices are small on their own. Together, they are why the connector layer needs to be a contract the business logic can trust, not a set of platform-specific calls scattered through the purchase-draft code.
What does ignoring this actually cost a group?
The failure mode we see is not dramatic, it is just late. A group signs an exclusive contract with one platform, priced on the parent entity’s volume. A subsidiary with a different profile — heavy consumer sales, a different e-reporting rhythm — does not fit that platform’s strengths as well. The group then has two bad options: force the mismatched entity onto a platform that serves it poorly, or rebuild the connector to add a second platform mid-programme, with a regulatory deadline that does not move. Both are more expensive than deciding the connector architecture before the first entity goes live.
The rebuild is rarely scoped honestly when it starts. It looks like “add a second platform,” and it turns out to mean re-reading every routine that assumed the first platform’s field names, its status vocabulary, its pagination — because that is where the coupling actually lived, not in a config file anyone remembered to keep separate. Teams that budget for “a new connector” and not for “an audit of everywhere the old one leaked” are the ones who miss the September deadline on the second entity, not the first.
Is running two platforms actually more expensive than running one?
Not in the way it first looks. The overhead of an interface-based connector is a one-time engineering cost, paid once, not per platform added afterward. The alternative — a point integration rebuilt every time a platform stops fitting — pays that cost repeatedly, usually against a deadline instead of on your own schedule. A group can still run one platform for the majority of entities and consolidate that volume for pricing; the interface is what makes adding a second platform for the outliers a contained change instead of a rewrite.
The Asio Services way
We did not start FacturaLink as a product line. We started it because a single-platform connector kept being the wall we hit while running Business Central programmes for multi-entity groups, and rebuilding the same connector logic per client was not a position we wanted to keep being in. If your group is weighing one certified platform against several, start with our clarity form — it is the fastest way to get a straight answer on what your entity mix actually needs.
FAQ
Does the French e-invoicing reform require one platform per group?
No. Nothing in the reform requires a single platform across a group, and different entity profiles often justify a split. The constraint is pricing, not regulation: since it is typically volume-degressive, splitting entities across platforms without a reason gives up a negotiating lever.
Can a group switch certified platforms after go-live?
Only cleanly if the connector was built to allow it. With a point integration, switching means finding and rewriting every place the old platform’s format is embedded in the business logic. With an interface-based connector, it means adding a new implementation of the same contract.
Does FacturaLink replace SuperPDP or Tréso2?
No. FacturaLink is the Business Central–side connector to a certified platform, not a certified platform itself. It currently connects to SuperPDP and Tréso2 through the same interface.
Is this only a concern for large groups?
It becomes relevant the moment a group has more than one entity with a meaningfully different invoicing profile — volume, B2B versus B2C mix, or e-reporting complexity. That threshold is lower than “large group.”