Here is a failure that catches competent teams. An organisation already exchanging Peppol invoices — successfully, for years, in another market — switches on Singapore. The invoices validate locally. The access point accepts them. And they are rejected.
Nothing is broken. The invoices genuinely are valid Peppol. They are just not valid here.
Peppol is a family, not a format
The mental model most people carry is that Peppol is one standard: make your invoice Peppol-compliant and it works everywhere on the network. That is roughly true of the transport layer, and not true of the documents moving across it.
Peppol defines a core invoice specification, and individual jurisdictions publish national variations on top of it. Singapore's is PINT-SG. Australia and New Zealand share PINT A-NZ. They descend from the same parent and they are not interchangeable.
A national variation exists precisely because a country's tax authority needs data the international core does not require. So the variation makes fields mandatory that are optional internationally, constrains values to code lists the authority publishes, and adds rules about how figures must reconcile. Each of those is a way a technically valid Peppol invoice can fail a national check.
Why your own validator says everything is fine
This is the part that wastes the most time. A system configured against the generic Peppol profile validates against the generic profile — and passes. It is doing exactly what it was asked to do. The check that matters happens later and somewhere else, against a stricter specification your system was never told about.
Two symptoms suggest this is what you are looking at. The first is invoices that fail in one market while identical documents succeed in another. The second is a rejection that names a field your team is certain is populated — because it is populated, just not in the form or from the code list Singapore requires.
The authority to check against is the specification itself. IMDA publishes Singapore's, and the Singapore Peppol guide is the reference to work from rather than a vendor summary — including a general comparison like this one.
Why this is not a criticism of Peppol
It is worth being fair here. The alternative to national variations is not one universal invoice; it is every country inventing its own format from scratch, which is the world Peppol was built to replace. A shared core with documented national extensions is a considerable improvement on that, and it is why an access point can route a Singapore invoice and a Finnish one across the same infrastructure.
The problem is not the design. It is that "Peppol-compliant" gets used in sales conversations as though it were binary, and buyers reasonably hear a guarantee that was never offered.
The question to ask a vendor
Not "are you Peppol-compliant?" — everyone says yes, and they are usually telling the truth about something narrower than you meant.
Ask instead: which specifications do you validate against, and which version? A straight answer names them and their versions. A vague answer is itself informative, because a provider who cannot name the specification is unlikely to be tracking its updates — and these specifications are revised. A configuration that was correct two releases ago is not automatically correct now.
The follow-up worth asking is what happens on rejection. Whether you find out immediately or at month end, whether the reason is legible or an error code, and whether anyone is watching for it — that determines how much of this ever reaches your AP team at all.
What PINT-SG means for GST InvoiceNow → · How our access point works →