A large buyer - typically an FMCG distributor or retailer with hundreds or thousands of suppliers - wants every supplier invoice reaching its AP process to be e-invoicing compliant, and decides to standardize this by offering all vendors a single ASP relationship through its vendor portal, rather than requiring every vendor to independently source and pay for their own ASP just to trade with this one customer. On paper this simplifies onboarding. In practice, it creates a structural problem the moment a vendor already has their own e-invoicing setup: that vendor’s ERP is already issuing compliant Peppol invoices to its other customers through its own ASP. If that same vendor is also asked to key or upload the same invoice into this customer’s portal, the invoice can now reach the buyer through two separate paths - once via the standard Peppol network (vendor’s own ASP → buyer), and once via the portal (vendor portal → customer’s sponsored ASP) - with real risk of duplicate AP posting, duplicate vendor effort, and confusion over which copy is the legally valid e-invoice.
The obvious design question is: which channel should a vendor actually use - their own ERP-to-ASP integration, or the vendor portal? The instinctive answer is to force a strict either/or: vendors who already have their own integration stay off the portal entirely, and portal vendors stay off it the moment they onboard their own ERP integration. In practice, that’s hard to enforce and even harder to explain across a vendor base of thousands - vendors change systems mid-year, onboard integrations gradually, or occasionally still need the portal for a one-off exception even after going live on their own ERP.
Our answer is that vendors shouldn’t have to be forced into one lane, and the buyer shouldn’t have to police it manually. Both channels can safely stay open at the same time - a vendor can keep using their own ERP-to-ASP integration while still retaining portal access, or the reverse - because the underlying middleware is built to recognize when the same invoice has already arrived through the other channel and block the duplicate before it ever reaches AP. That’s a capability we’ve engineered specifically for live vendor-portal deployments, and it’s the difference between a policy someone has to enforce by hand and one the platform enforces on its own. The specific signals, tolerances and sequencing logic behind that detection are exactly the kind of detail worth walking through directly with our team rather than summarizing in a use case.
Middleware is what makes this flexibility practical rather than risky. Without it, the portal would need to independently implement PINT AE structural validation, Peppol transport formatting, ASP integration, and duplicate protection - duplicating work that belongs in one shared compliance layer. With middleware sitting behind the portal, the Vendor Portal itself validates business-level, portal-specific rules - mandatory fields present, vendor is registered/approved, GRN reference exists and is valid, amounts are within expected tolerance of the PO or GRN, attachments are readable. The middleware then validates everything the portal isn’t positioned to check - PINT AE/UBL 2.1 schema conformance, tax calculation and rounding rules, Peppol transport-level requirements, and the cross-channel duplicate protection described above. Exactly where that line sits, and how the duplicate check is tuned for a specific vendor base, is part of the implementation - worth a conversation with us rather than a checklist.
Why one ASP for the customer and all sponsored vendors is worth doing, even though Peppol doesn’t require it: reconciliation is simpler against one ASP’s status API instead of many; exception handling is faster with one support relationship and one error-code taxonomy to interpret instead of several; the customer gets real volume-based commercial leverage negotiating bulk ASP pricing across its whole long-tail vendor base; and onboarding UX is consistent - one Peppol ID issuance, testing and go-live flow built into the portal, instead of supporting many different ASPs’ onboarding journeys. The trade-off is concentration risk (single-ASP dependency) and vendor lock-in concerns for larger suppliers - which is exactly why this should be positioned as sponsorship for the long tail, not a mandate for every vendor: enterprise suppliers who already bring their own ASP should be allowed to stay on the open Peppol network rather than being forced onto the customer’s ASP.
On who pays: there’s no regulatory answer, only commercial convention. As a rule, the outbound leg is naturally borne by whoever issues the invoice - so a vendor using their own ERP and ASP bears that cost themselves, as they would with any other customer. For vendors sponsored on the customer’s ASP through the portal, the customer typically negotiates bulk/tiered pricing and either absorbs it outright for small or strategic suppliers (a common procurement-efficiency investment in retail, FMCG and construction, where the supplier base is large and fragmented), passes a modest reduced per-invoice fee to the vendor, or nets it against payment terms or an early-payment program. Vendor onboarding effort itself - configuring the vendor’s record, issuing portal access, initial testing - is almost always funded by the customer, since the portal and the onboarding flow are the customer’s asset.
Pros and cons for suppliers, purely on compliance: the upside is real - a smaller vendor gets compliant e-invoicing without having to shop for, contract, and pay for their own ASP, and onboarding is faster because it’s built into a portal they already use. The downside is equally real - the vendor becomes dependent on this one customer’s portal and ASP relationship for this trading relationship specifically, gains no reusable e-invoicing capability for their other customers, and must stay disciplined about not duplicating invoices if they later adopt their own ERP-based e-invoicing (at which point the contract terms restricting portal use to exceptions become essential, not optional).
Why this fits FMCG particularly well: FMCG buyers routinely carry supplier bases running into the thousands - distributors, small manufacturers, packaging vendors, promotional/trade-spend suppliers - many of whom are genuinely too small to justify their own ASP relationship. High invoice volume, high vendor fragmentation, and low average invoice value per long-tail supplier is exactly the profile where sponsoring compliance through one portal and one ASP pays for itself in procurement efficiency and supplier goodwill, while the reconciliation engine protects the buyer from the duplicate-posting risk that this exact profile of business - many vendors, many channels, high transaction volume - would otherwise create at scale.
Tell us about your ERP and the mandate you fall under — we’ll show you how we’d handle it.