SOPs, Governance & Controls

The ASP and ERP integration ensure invoice data can move correctly through the Continuous Transaction Control network, but they do not decide whether a given invoice should have been issued in the first place, at the right value, with the right approval, or with accurate master data behind it. Those are governance questions, not technical ones. Because the network reports invoices close to the point of transaction, an ungoverned error is reported to the FTA almost immediately, with no periodic review window left to catch it quietly beforehand.

Segregation of duties means no single person can both create and approve the same transaction, or both amend customer master data and issue an invoice to that same customer, without an independent check. Under periodic invoicing, a segregation gap might be caught at month-end review. Under Continuous Transaction Control, the same gap allows an unauthorised or erroneous invoice to reach the FTA before anyone else reviews it, which is why PNPC treats segregation-of-duties mapping as a core, non-optional part of SOP design for e-invoicing.

This depends on your company's existing governance structure and shareholder expectations. For many SMEs, documented management sign-off is sufficient and proportionate. For larger companies, groups with external investors, or companies where the board is actively involved in financial policy, formal board approval is the stronger position. What matters most is that adoption is documented in some form — a signed policy with no record of who approved it, and when, is weaker evidence if an auditor or the FTA later asks how the governance framework was established.

At minimum: what to do when the ASP or FTA network rejects a submission, what to do during a genuine connectivity or system outage, how a rejected invoice is corrected and resubmitted, who is accountable for resolving each exception type, and the maximum time allowed before an unresolved exception is escalated to management. A playbook without a named accountable role and a resolution deadline tends to leave exceptions sitting unresolved, which compounds risk the longer they remain open.

Taxable and exempt persons must retain records sufficient for the Federal Tax Authority to verify their Corporate Tax position for at least seven years after the end of the relevant tax period. E-invoice data, ASP transmission logs, and any exception or override approvals form part of that evidence trail. PNPC designs the archiving and retention policy as part of SOP design specifically so these records remain retrievable, indexed by period and entity, for the full retention window — not simply stored somewhere without a retrieval plan.

This should be a materially tighter control than standard invoice approval, because credit notes and cancellations are the transaction types most exposed to misuse — reversing revenue, correcting an error inappropriately, or covering an unauthorised discount. PNPC typically recommends a higher approval level than standard invoicing, mandatory documented justification for every credit note, and a periodic review of credit note volume and pattern by someone independent of the person issuing them.

This is exactly the scenario SOP design has to anticipate rather than assume away. PNPC builds a realistic exception path for genuinely urgent situations — a documented fast-track approval with a lower-friction but still logged sign-off, rather than an unofficial bypass that leaves no trail at all. A policy with no legitimate fast path for real urgency tends to get informally bypassed anyway, which is worse than designing a controlled fast path from the outset.

PNPC recommends a quarterly control refresh as a baseline — reviewing access rights, the approval matrix, and exception-handling assignments — plus an ad hoc review whenever the Ministry of Finance or FTA publishes further detail on the e-invoicing programme's phased scope, thresholds, or requirements, since the framework continues to evolve as the rollout matures.

PNPC runs the staff training as part of the engagement, with role-specific sessions for invoice issuers, approvers, and master-data custodians rather than a single generic session for everyone. We find role-specific training is materially more effective, since each group needs different, specific guidance rather than a broad overview of the entire policy.

The need scales with complexity — number of staff issuing invoices, number of entities, and transaction volume — but the underlying principle applies to any business bringing invoice issuance under a Continuous Transaction Control model. A single owner-operator issuing a handful of invoices personally may only need a lightweight checklist. A business with multiple invoicing staff, multiple entities, or meaningful credit note volume needs a formal, documented SOP framework to manage the real segregation-of-duties and exception risk that scale introduces.

Master data governance is the policy controlling who can create, amend, or deactivate customer and supplier records — the records that supply the Tax Registration Number, legal entity name, and address information a structured e-invoice depends on. It is a priority because a single unauthorised or erroneous master-data change can silently corrupt every subsequent e-invoice generated against that record, and because master data is frequently the least controlled part of a business's existing process, having grown informally over time.

Where entities share staff, systems, or invoicing processes, PNPC designs a consistent governance framework applied across both, adapted only where each entity's specific licensing, VAT registration, or Corporate Tax position genuinely requires a different treatment. Applying inconsistent, entity-specific governance where the underlying process is actually shared tends to create confusion and gaps at the boundary between entities.

Evidence that the documented SOPs actually operated in practice, not just that a policy document exists — approved invoices showing the required sign-off, a master-data change log showing authorisation, exception records showing how a rejected invoice was resolved, and a formal adoption record showing when and by whom the governance framework was approved. A well-written SOP with no operating evidence behind it is a weaker position than a simpler SOP that is clearly and consistently followed.

For a single-entity business with a reasonably formal existing approval process, the full cycle — from scoping through drafting, workshops, training, and go-live monitoring — typically takes five to six weeks. Multi-entity groups, businesses with several invoicing departments, or businesses starting from an entirely informal control environment take longer, since the roles and segregation-of-duties mapping step expands with each additional department or entity.

A strong existing process is a good starting point, not a reason to skip governance design entirely. PNPC still reviews it specifically against the risks a Continuous Transaction Control model introduces — the removal of a periodic correction window, the higher exposure of credit notes and master-data changes, and the record-retention requirements for continuously reported data. In many cases the engagement is materially shorter because it builds on and formalises what already works, rather than designing a framework from nothing.

This engagement covers design, drafting, workshops, training, and a go-live monitoring window to catch and adjust for practical issues. Ongoing operational support, monitoring, and periodic control checks after that initial window are covered under our Post Go-Live Support service, which many clients run alongside or immediately following SOP design, ensuring continuity rather than a handoff gap between the two.

Through the workshop and testing stage, where the draft SOP is applied to real recent transactions from each department before it is finalised, through role-specific training rather than a generic policy announcement, and through the go-live monitoring window that adjusts the SOP where it proves impractical against real conditions. PNPC also recommends a quarterly control refresh specifically to catch drift before an unfollowed SOP becomes the normal, unquestioned practice.

The underlying SOP structure — approval matrix, segregation of duties, exception handling — is the same for both, but a Qualifying Free Zone Person needs an additional layer that tracks the counterparty type (Mainland versus Free Zone) and the qualifying versus non-qualifying nature of each revenue stream at the point of invoicing, since this composition is part of what supports the 0% Corporate Tax treatment on qualifying income. A standard Mainland company generally does not need this extra characterisation layer unless it is transacting with Free Zone group entities.

Yes, in most cases. The FTA's e-invoicing programme is being rolled out in phases by taxpayer segment, and businesses not yet in a mandatory phase can still adopt structured e-invoicing voluntarily. Even setting voluntary adoption aside, the segregation-of-duties gaps and master-data weaknesses this engagement identifies are usually present in a business's invoicing process regardless of e-invoicing, and are worth closing before continuous reporting removes the safety net of a periodic review — not after.

They need governance, but not necessarily identical rules. Intercompany invoicing between related entities in the same group — particularly across a free zone and mainland pairing — sits in a distinct category: it is not ordinary external invoicing, but it is not purely internal either, since it still flows through the e-invoicing network and carries VAT and Corporate Tax related-party implications. PNPC designs a specific, documented procedure for intercompany invoicing rather than leaving it ambiguously covered by the general external-invoicing approval matrix.

The underlying approval, segregation-of-duties, and exception-handling principles apply to both, but the practical control points differ — B2C transactions are often higher-volume and lower-value, so the approval matrix typically relies more on system-configured thresholds and post-transaction sampling than on individual pre-approval for every invoice, whereas B2B invoicing more often warrants transaction-level review given typically higher values and more complex customer relationships. PNPC tailors the control intensity to the actual risk profile of each transaction type rather than applying one uniform threshold across both.

Because the original invoice has already been reported through the Continuous Transaction Control network, the correction is generally made through a properly authorised credit note, debit note, or replacement invoice following the applicable rules, rather than by attempting to alter or withdraw the original record. PNPC's SOP design documents this correction path explicitly, including who is authorised to approve the correcting document and what evidence must support it.

PNPC builds the e-invoicing-specific SOPs to integrate with, not duplicate or replace, an existing ISO-certified control framework or internal audit function. Where a mature control environment already exists, the engagement typically focuses on the specific gaps a Continuous Transaction Control model exposes — segregation of duties for master-data changes, credit-note governance, and exception handling — rather than rebuilding controls that already work well.

PNPC builds a small set of practical indicators into the quarterly control refresh — the trend in ASP or FTA rejection rates, how long exceptions typically stay open before resolution, the pattern and volume of credit notes by issuer, and whether master-data changes are consistently logged with proper authorisation. A rising trend in any of these, tracked consistently over time, is a more reliable early signal than waiting for an actual incident to reveal that a control has quietly stopped working.

Some initial friction is normal and expected, which is why PNPC builds a legitimate, documented fast-track path for genuine urgency into the SOP from the outset, rather than leaving staff to informally bypass the process when it feels slow. Role-specific training that explains the reasoning behind each control — not just the mechanics of it — also materially reduces resistance, because staff who understand why continuous reporting has raised the stakes tend to follow the process rather than work around it.

The exception-handling playbook PNPC designs covers both scenarios distinctly — an ASP-side rejection or outage, and a broader network or FTA-side disruption — since the appropriate response and any permitted fallback procedure can differ between the two. In either case, the playbook names an accountable role, a documented fallback or holding procedure, and a resubmission process once the connection is restored, so staff are not left improvising during a genuine system-wide disruption.

Electronic approval is generally acceptable, provided it produces a clear, auditable trail showing who approved what, when, and on what basis — a logged approval within the ERP or accounting platform itself is usually stronger evidence than a separate paper sign-off that can be misplaced. PNPC configures the approval workflow within the client's existing system wherever the platform supports it, rather than adding a parallel paper process on top of a system that could handle the approval natively.

No, not as a core scope item. Anti-Money Laundering compliance — customer due diligence, goAML reporting, and the obligations of Designated Non-Financial Businesses and Professions under the Ministry of Economy's AML framework — is a distinct regulatory obligation from e-invoicing governance, even though both touch customer master data. Where PNPC identifies an overlap or gap relevant to AML during this engagement, we flag it, but a formal AML compliance programme is scoped and delivered as its own engagement.

No. PNPC designs the SOPs and the control framework; an internal audit function's role is typically to independently test whether that framework is actually operating as documented, on an ongoing basis. The two roles are complementary — PNPC can brief internal audit on the design logic and evidence trail during the engagement so their subsequent testing is informed and efficient, but the testing role itself stays with internal audit.

A system migration is a trigger for re-testing, not necessarily rewriting, the governance framework, since a new platform's access-control model, approval-workflow configuration, and audit-trail capability may differ meaningfully from the system the SOPs were originally designed around. PNPC recommends re-validating the approval matrix and segregation-of-duties mapping against the new system before go-live on it, so permissions carry across deliberately rather than defaulting to whatever the new platform ships with out of the box.

Not automatically, though the existing framework is usually the starting point rather than a blank page. PNPC reviews the new entity's licensing, VAT/Corporate Tax registration status, staffing, and invoicing volume, and extends the group's existing SOPs where the process is genuinely shared, while adapting specific elements — the approval matrix, master-data ownership — where the new entity's structure or activity requires a different treatment.

The core governance — approval matrix, segregation of duties, master-data policy, record-retention design — generally stays valid across an ASP change, since these are business-process controls rather than vendor-specific configuration. What does need updating is the exception-handling playbook's vendor-specific detail: the new ASP's rejection codes, technical contact points, and any process quirks specific to that provider's platform.

This depends on your workforce and internal documentation practice rather than a fixed FTA requirement on the SOP document itself. PNPC can prepare bilingual documentation where a business's invoicing or finance staff are more comfortable working in Arabic, or where group policy requires it, alongside the English version used for management and board-level sign-off.

The e-invoicing programme's phased rollout is generally tied to a business's registration status and size rather than applying to every unregistered entity immediately, so a business below the VAT registration threshold and not yet Corporate Tax registered may not be in scope yet. It is still worth monitoring where your business sits relative to the registration thresholds, since crossing either threshold can bring e-invoicing obligations, and the underlying governance principles are worth adopting early regardless of the formal trigger.

The Risk Advisory SOP Design service builds enterprise-wide standard operating procedures across a business's broader operational, financial, and risk processes. This engagement is scoped specifically to e-invoicing — the approval matrix, segregation of duties, and exception handling that govern invoice issuance under the Continuous Transaction Control model. The two can be run together for a business undertaking a wider controls overhaul, but this engagement does not require the broader Risk Advisory scope to be commissioned first.

The FTA does not mandate a specific SOP document by name. What is a legal requirement is accurate invoice reporting and record-keeping sufficient to substantiate VAT and Corporate Tax positions under the relevant Federal Decree-Laws. Written SOPs, an approval matrix, and documented segregation of duties are the practical mechanism PNPC recommends for reliably meeting that underlying legal obligation once reporting becomes continuous — not a separate, freestanding legal requirement in their own right.

Documented, properly followed SOPs reduce the likelihood of the errors — wrong VAT treatment, duplicate submissions, unauthorised master-data changes — that tend to trigger FTA queries and penalty exposure in the first place, and they give you a clearer evidence trail if the FTA does raise a question. PNPC does not represent that documentation alone eliminates penalty risk or guarantees a specific outcome in any individual case; the value is in genuinely reducing the errors and strengthening your evidence position, not in a formal penalty guarantee.

The approval principles are the same, but PNPC's SOPs specifically document the exchange-rate source and application point for foreign-currency invoices, and require the same approval evidence as an AED-denominated invoice of equivalent value — since a foreign-currency invoice can otherwise become a way an approval threshold is inadvertently bypassed if the AED-equivalent value is not clearly calculated and checked at the point of approval.

Not as a mandatory part of this engagement, but PNPC recommends briefing your statutory auditor on the finalised SOPs and evidence trail ahead of the year-end audit, particularly where e-invoicing governance is new. An auditor who understands the control framework and where the supporting evidence lives before audit fieldwork begins can test it more efficiently than one encountering the framework for the first time during the audit itself.

An ERP-embedded workflow is a valuable technical enabler, but it is not the same as a documented governance framework — it typically automates the mechanics of routing an approval, without necessarily reflecting a deliberately designed approval matrix, segregation-of-duties analysis, or exception-handling playbook specific to e-invoicing's continuous reporting risk. PNPC reviews the existing workflow configuration and designs the governance logic it should be enforcing, which is often narrower and faster than building from nothing.

The approval matrix and exception-handling design account for realistic peak-period volume, not just an average month, since a control that works fine most of the year but breaks down during a seasonal spike creates exactly the kind of pressure that leads staff to bypass documented procedures. PNPC discusses seasonality explicitly during scoping so the fast-track and escalation paths are genuinely workable under peak conditions, not just in a quiet month.