Three of the profiles PeppolBridge emits today — PINT AE (UAE), PINT MY (Malaysia) and Peppol BIS Billing 3.0 (Belgium) — look interchangeable from a sales deck and meaningfully different from a debugger. This is the engineering view.
First, what PINT is
Peppol BIS Billing 3.0 was built on the European semantic standard EN 16931 — excellent for the EU, awkward for jurisdictions with different tax constructs. OpenPeppol's answer is PINT, the Peppol International invoice model: a shared core that each jurisdiction extends with a specialization. PINT A-NZ, PINT SG and PINT JP came first; PINT MY and PINT AE followed, and Oman's specialization is expected next.
The three profiles in practice
| BIS Billing 3.0 | PINT AE | PINT MY | |
|---|---|---|---|
| Jurisdiction | Belgium (and the EU B2G world) | UAE | Malaysia |
| Base | EN 16931, no national CIUS in Belgium | PINT core + UAE specialization | PINT core + MY specialization |
| Field profile | EN 16931 semantic model | ~51 mandatory fields (tax invoice), 49 (commercial) | MyInvois data model + UIN carriage |
| Exchange | 4-corner Peppol | 5-corner DCTCE via ASPs | Optional 4-corner Peppol over mandatory clearance |
| Clearance? | No | No (reporting, not clearance) | Yes — LHDN validates and issues a UIN first |
| Authority | FPS Finance / BOSA | MoF + FTA | LHDN; MDEC as Peppol Authority |
Where implementations actually break
The XML bones are all UBL; the pain is in the business rules. PINT AE encodes UAE VAT categories and emirate-level specifics, and is built for near-real-time FTA reporting. PINT MY is unusual because Peppol is the second layer: every invoice must first clear MyInvois and receive its Unique Identifier Number, which the Peppol payload then carries — get the sequencing wrong and you emit structurally valid, legally meaningless documents. Belgium is the most permissive (any EN 16931 format by agreement, Peppol receivability mandatory) but the buyer's VAT deduction rides on correctness, which concentrates the risk in validation rather than transport.
The architectural conclusion
If you implement these as three codebases, every regulation update forks three times. The alternative — the one PeppolBridge is built on — is a canonical invoice model with country rule-packs: extraction and normalization happen once, and each profile is a versioned emission target. When the UAE amends a business rule or Malaysia adjusts consolidation thresholds, the change ships as configuration, and no client integration moves. That is what "country-agnostic" means at the engineering level — see the architecture.
One platform. Every profile.
PINT AE, PINT MY and BIS 3.0 are emission targets on the same pipeline. Bring your hardest mapping question to a call.