Do I need new invoicing software, or can I wire compliance into the system I already run? That is the question landing on the desks of CFOs and CIOs at large companies operating in Morocco now that DGI e-invoicing has moved from a watch-list item to a dated legal obligation. The good news: in most cases, the answer is not "replace your software." It is "connect what you already have, correctly."
What the mandate requires, in one page, and where to verify the timeline yourself
The legal basis is Article 145 (IX) of Morocco's General Tax Code, introduced by the 2018 Finance Law and tightened by the 2024 Finance Law: companies subject to corporate tax, professional income tax, or VAT must equip themselves with an electronic invoicing system meeting technical criteria set by the tax administration (the DGI). Note Circulaire n°737, covering the 2026 Finance Law's tax measures, spells out the application details.
The rollout timeline most widely cited by trade press and vendors places the obligation at January 1, 2026 for large companies subject to corporate tax, July 1, 2026 for mid-sized companies with turnover between roughly 10 and 200 million MAD, and January 1, 2027 for SMEs, micro-enterprises, and self-employed professionals whose annual turnover exceeds 500,000 MAD. One caution for your compliance team: the exact thresholds and final effective dates are set by the implementing decree, which was still being finalized as this article was written. Do not lock an internal project plan to a figure lifted from a vendor blog; verify the current version directly on the DGI portal (tax.gov.ma) and in Note Circulaire n°737, and have your tax advisor confirm before you commit a budget.
What is confirmed without ambiguity: the required format is structured (UBL 2.1 or CII, both XML standards), and Morocco has adopted a "clearance" model: every invoice must pass through the DGI's platform and be validated there before it is legally considered issued. A non-compliant invoice carries a fine of 500 MAD, capped at 50,000 MAD per year, and eventually the loss of VAT deductibility for invoices that fail the format check. The mandate itself is already well documented elsewhere; that is not what this article is about. The part most guides skip is what happens between your systems and the DGI's platform.
The real question: who emits the structured invoice, your system or a third party
Most articles on this topic stop at "you must issue invoices in XML." They skip the question an IT leader actually needs answered: who, in the chain, generates that structured file?
Two architectures are reportedly under review by the DGI. A "4-corner" model, where the supplier transmits the invoice simultaneously to its client and to the tax authority, with no mandatory technical intermediary. A "5-corner" model, where an accredited third-party operator sits in the middle to validate the format, timestamp the invoice, and transmit it to the DGI on the supplier's behalf. Morocco already has accredited providers for adjacent electronic-certification functions, such as Barid eSign (a subsidiary of Barid Al-Maghrib), which suggests the 5-corner model, or a hybrid variant, has a reasonable chance of applying to at least part of the market.
In practice, this means your ERP almost never needs to emit the final DGI-validated invoice itself. Its job is narrower and more precise: produce the right data, in the right format, at the right point in the flow, so your invoicing software vendor or an accredited provider handles the last leg to the platform. Confusing the two roles is the most common source of delay we see in compliance projects: an IT team tries to rebuild a full emission module in-house, when the actual missing piece is a connector between the ERP and a module that is already certified.
What your system must produce: mandatory data, format, signature
Three technical requirements shape the scope of work, regardless of which vendor or integrator you choose.
Mandatory data fields. Full tax identifiers for both client and supplier (the Moroccan ICE, IF and RC registration numbers), VAT detail by line and by rate, a unique invoice reference, unambiguous currency and amounts, and links back to underlying purchase orders or contracts wherever your procurement process requires them. An ERP that leaves these fields optional at data-entry time is, in effect, non-compliant.
The structured format. UBL 2.1 or CII are not generic export formats like a CSV or PDF; they are XML schemas with an enforced tag structure. Your system either generates this format natively (rare, outside recent ERPs with a dedicated Morocco module), or exposes the underlying data through an API or file feed to a transformation module that produces the compliant XML.
Signature and timestamping. A DGI-compliant invoice is not a manually signed PDF. It carries an electronic signature and a timestamp that guarantee its integrity after issuance. This piece is almost always delegated to the invoicing module vendor or the accredited provider rather than built in-house: a security and compliance choice, not just a convenience one.
The company billing from three different tools
The most common scenario at large companies isn't "one ERP that handles all invoicing." It is invoicing scattered across several systems: a central ERP for recurring sales, a services or project-management tool for fixed-fee billing, and a spreadsheet or standalone application for edge cases (credit notes, internal cross-charges between subsidiaries, one-off engagements).
Every one of those flows has to reach the DGI's platform in the same structured format, with the same rigor on mandatory data. You have three options. First: consolidate all invoicing flows into the central ERP before issuance, which means feeding data from the peripheral tools into the ERP via API or automated import, then letting the ERP alone carry the connection to the e-invoicing module. Second: connect each tool separately to a shared e-invoicing module or provider, which multiplies integration points but avoids a heavy consolidation project. Third, often the most realistic for a twelve-to-sixteen-week rollout: an intermediate integration layer (middleware or an exchange platform) that ingests billing data from each source, normalizes it into a common format, then pushes it to the chosen e-invoicing module. That is precisely the role a well-designed systems integration layer plays: it avoids duplicating tax-compliance logic across three separate tools.
Receiving compliant invoices from your suppliers: the half of the problem everyone skips
Nearly every guide to Morocco's DGI e-invoicing mandate covers only the outbound direction: how your invoice reaches your client and the tax authority. They skip the inbound half of the problem, which weighs just as heavily on a large company: what do you do with the compliant, structured invoices your major suppliers start sending you?
Two common mistakes. The first: continuing to treat supplier invoices as PDFs that an accounts-payable clerk keys back into the purchasing ERP by hand, ignoring the structured XML file that comes attached, which wipes out the traceability benefit of the reform and multiplies keying errors. The second: discovering, only when the first wave of compliant invoices arrives at scale, that the accounting module cannot parse a UBL or CII file and blocks automated matching.
The right approach is to build an inbound flow during the scoping phase, not after go-live: capture the structured file received from the supplier, extract the data for automated three-way matching against the purchase order and goods receipt, and keep the PDF only as a human-readable archive copy. This piece should be scoped alongside the outbound flow (it is the same kind of connector, running the other direction), rather than as a second project six months later.
Vendor, integrator, accredited provider: a RACI matrix
A compliance project that slips on the calendar almost always has the same root cause: nobody wrote down, formally, who does what between the ERP or invoicing software vendor, the integrator connecting the systems, and the accredited provider handling the technical relationship with the DGI's platform. Here is a matrix to adapt to your organization (R = responsible for execution, A = accountable for the outcome, C = consulted, I = informed):
| Task | Client (CFO/CIO) | ERP/invoicing vendor | Integrator | Accredited provider |
|---|---|---|---|---|
| Define mandatory data per flow | A | C | R | C |
| Build/configure the connector from source systems | I | C | R | I |
| Generate the structured format (UBL/CII) | I | R | C | A |
| Sign and timestamp the invoice | I | C | I | R |
| Transmit to the DGI platform, handle rejections | A | I | C | R |
| Process compliant inbound supplier invoices | A | C | R | I |
| Track regulatory changes (thresholds, timeline, format) | A | C | I | C |
This matrix is not universal: if your company issues directly through a certified ERP module without a third-party provider (the 4-corner model), the "accredited provider" column shrinks. What matters is fixing it in writing before development starts, not during it.
The requirements block to paste into your RFP
For a vendor RFP or an internal brief, here are the minimum requirements to put in writing:
- Generation or transformation of outbound flows into UBL 2.1 or CII, with traceability on every mandatory field (ICE, IF, RC, VAT by line).
- Ability to consolidate multiple internal billing sources (ERP, fixed-fee billing tool, inter-subsidiary cross-charges) before transmission.
- Electronic signature and timestamping delegated to a certified component, with integrity proof retained and available for audit.
- Inbound handling: reception, parsing, and automated matching of compliant supplier invoices, archiving the PDF as a read-only copy only.
- Full logging of DGI platform rejections, with a correction-and-resubmission window defined contractually with the integrator.
- A regulatory-update clause: whether the vendor or the integrator owns adapting the connector when the format or thresholds change, and within what deadline.
- An end-to-end test plan before cutover, including at least one full cycle of a validated outbound invoice and a matched inbound supplier invoice.
This scope can lean on a dedicated API integration when your existing systems already expose modern APIs, or on a broader business-application modernization effort when the ERP in place cannot expose that data without additional development.
What is still likely to change, and how not to pay for it twice
Three things are not yet settled as this article is being written: the final choice between the 4-corner and 5-corner models, the exact turnover thresholds per wave, and the final list of accredited providers. Hard-coding your connector around a single assumption (say, a direct, exclusive link to one specific provider) means redoing the development the moment the implementing decree finalizes the architecture.
The fix is architectural, not regulatory: isolate the transformation and tax-compliance logic in a dedicated integration layer rather than embedding it in each source application. If the format changes tomorrow, or a new accredited provider enters the market, you swap a connector in the integration layer instead of rewriting business logic across three different applications. That is the same principle behind systems integration built to outlast a single tax reform, echoed in our guide to information-system modernization: consolidating silos up front always costs less than doing it after a second regulatory mandate forces the issue.
FAQ
Do I need to replace my ERP to comply with DGI e-invoicing?
In most cases, no. Your ERP needs to produce or expose the right data; generating the structured format and the signature is usually delegated to an e-invoicing module or an accredited provider. A full ERP replacement is only justified if your current system technically cannot expose the mandatory data, even through an API.
What invoice format does the DGI require?
A structured XML format, either UBL 2.1 or CII. These standards are not interchangeable with a simple PDF or CSV export: they enforce a precise tag structure for every mandatory data field (tax identifiers, VAT by line, unique reference).
What if I invoice from several different tools?
Every flow needs to reach the DGI platform in the same compliant format. The most durable solution is an intermediate integration layer that normalizes data from each source before transmission, rather than duplicating compliance logic inside every tool.
Do I also need to handle invoices I receive from suppliers?
Yes, and it is the part most companies overlook. An inbound flow that automatically captures and matches compliant supplier invoices prevents your accounts-payable team from losing the reform's benefit, and avoids a matching bottleneck once your larger suppliers switch over.
Is the DGI e-invoicing timeline final?
The principle and the broad milestones are set by the Finance Law and Note Circulaire n°737, but some exact thresholds remain subject to an implementing decree still being finalized. Check the current version on tax.gov.ma before locking in a budget or an internal timeline, and have your tax advisor confirm it.