Ask three UAE finance teams where their AP invoicing logic physically runs and you will get three different architectures — and each one fails in a different place.
The question matters more this year than last, because the ASP appointment deadline is forcing procurement decisions while providers market validation and determination services layered on top of bare transmission. Buying those services moves a share of AP logic outside the enterprise's own change control. That can be a reasonable trade. It stops being reasonable when nobody records that it happened.
Integrated AP
Integrated AP runs invoicing and accounts payable entirely inside the ERP, with tax determination, validation and transmission logic configured as native or tightly embedded ERP functionality, and the ASP connection treated as one more integration point off the same system of record. Governance concentrates in one place: the ERP's own change control, access management and configuration discipline apply to the whole invoicing process.
The risk concentrates in the same place. A defect in the ERP's configuration or a gap in its change control affects the entire invoicing function at once, with no independent layer positioned to catch what the ERP itself missed. An enterprise running this model should point its assessment at ERP change control — who can alter a tax determination table, what testing gate stands between that change and production, and how a wrong change would be detected if it validated cleanly.
AP-on-ASP
AP-on-ASP describes an architecture where a meaningful share of invoicing logic — validation, formatting, even elements of tax determination — is delegated to functionality the Accredited Service Provider offers beyond bare transmission, rather than built and governed inside the enterprise's own systems. For an enterprise with limited internal technology capacity, the efficiency case is real.
The governance risk sits in the contracted scope of the ASP relationship. Accreditation certifies the provider, not the enterprise's tax correctness, and an enterprise that delegates validation logic without governing what that logic actually does has moved the technical work outside its walls without moving the accountability that stays, by law, inside them. The assessment question is narrow and answerable: what exactly does the value-added service validate against, when was that ruleset last updated, and how would the enterprise learn that it had changed? An enterprise that has never asked has not confirmed coverage. It has not yet found the gap.
ERP-native AP with a separate compliance layer
The third model sits between the two. The ERP remains the system of record for the transaction and the underlying accounting entry, while a dedicated compliance layer — a source-integrated transmission path, a middleware architecture, or a combination — handles the transformation and transmission logic specifically required for PINT AE conformance. Enterprises operating across a fragmented system landscape usually arrive here, because it lets the ERP stay the accounting source of truth while the specialised, frequently-changing compliance logic lives in a layer built for that purpose.
The risk concentrates in that layer's currency and completeness. A mapping written against last year's specification will keep transmitting successfully until the day it does not, and a transaction type introduced by the business after the layer was built may never have been mapped at all. The assessment question is whether the compliance layer's rule set is versioned against the PINT AE release it was built for, and who is accountable for closing the lag when a new release lands.
What to do with this
None of the three models is inherently more compliant than the others. Each concentrates governance risk in a different place, and the practitioner task is to state explicitly which model the business is running and direct the Business Process Impact Assessment at that model's specific concentration point — the ERP's configuration discipline, the ASP relationship's contracted scope, or the integration layer's currency — instead of applying a generic assessment that assumes a different architecture than the one actually in place.
Most enterprises can answer this in a single meeting, and the answer usually surprises somebody in the room. That surprise is the finding.