Moroccan E-Invoice Formats: UBL 2.1, CII and the PDF Question

The short answer. A Moroccan electronic invoice must be a structured XML file, not a PDF. Sources agree on two formats: UBL 2.1 (OASIS) and CII (UN/CEFACT). Beyond that (notably whether a human-readable PDF/A-3 must accompany the XML) published claims contradict one another, and no final technical specification has appeared in the Bulletin Officiel to date. This guide separates what is consistently reported from what rests on no verifiable source, and gives you the questions to put to a software vendor.

Why a PDF is not enough

This is the most common misunderstanding, and an expensive one, because it creates the illusion of already being compliant.

An invoice in PDF form (emailed, even electronically signed) is not an electronic invoice in the sense of the reform. The reason is technical rather than administrative: the DGI platform must read and check each invoice automatically before validating it. A PDF is built to be read by a human; its data is positioned visually, not structured.

A structured XML file, by contrast, exposes each value in an identified field: seller identifier, buyer identifier, invoice line, VAT rate, totals. That is what makes automated checking possible across millions of invoices.

The practical consequence: if your current software "exports to PDF", that gets you nowhere on compliance. The question to put to your vendor is not "can we email invoices" but "do you produce UBL 2.1 or CII".

UBL 2.1: the most frequently cited format

UBL (Universal Business Language) is an XML standard maintained by OASIS. It is the most widely deployed format internationally, particularly across the European Union, and it is the one Moroccan sources cite first, several present it as the national platform's reference format.

The expected version is UBL 2.1.

In practice, a UBL invoice describes in an XML tree: issuer and recipient with their identifiers, document references, each invoice line, applied taxes and totals. A vendor already fluent in UBL for another market has done much of the work, but not all of it, since national business rules (mandatory mentions, Moroccan identifiers) still have to be built in.

CII: the UN/CEFACT alternative

CII (Cross-Industry Invoice) is the other XML format cited, standardized by UN/CEFACT. It does the same job as UBL with a different structure, and is likewise widely used internationally.

Here the sources diverge, and it is worth noting:

• Several providers and consultancies state that both UBL 2.1 and CII are accepted;
• At least one vendor asserts that UBL 2.1 is the single format retained by the DGI.

Neither claim rests on a published official text. In practice this changes little about your preparation: a system that can produce UBL 2.1 covers the most likely scenario, and the substantive work (structuring your data, cleaning up identifiers) is common to both formats.

The contested point: is PDF/A-3 mandatory?

This is where the available content contradicts itself most directly, and it is worth pausing on.

PDF/A-3 is a particular flavor of PDF: it allows a file (here, the XML) to be embedded inside the document. You get a single artifact, readable by a human on screen and containing machine-usable structured data. This is the principle behind the hybrid Factur-X format used in France.

What is actually published on the subject:

In other words: the most demanding requirement is also the least sourced. We are not saying it is wrong: it may well appear in the final specifications. We are pointing out that it is currently supported by no published text, and that a software decision should not rest on it alone.

The reasonable position: favor a vendor that can produce structured XML and generate a readable representation of the document. That covers both scenarios without overpaying for a feature presented as mandatory while remaining undocumented.

What the format actually demands of your system

These are requirements on your data, distinct from the transmission and archiving obligations covered in the main guide:

Read that list against your current setup. If your invoices come out of a spreadsheet, or from software where the customer ICE is a free field that is sometimes empty, the format is not your first problem: your data is. That is the point most available content skips, because it cannot be solved by buying a tool. We cover it in detail in ICE, archiving and integrity: is your data ready?, including a test you can run yourself in a day.

How to test whether software is genuinely ready

Seven questions to put to a vendor, and what a good answer looks like:

1. "Do you produce UBL 2.1? Can you show me a sample file?" A ready vendor produces XML in thirty seconds. An evasive answer is itself an answer.
2. "Do you handle CII as well?" No is not disqualifying, but the answer tells you about maturity.
3. "How do you handle platform rejections?" You need a process for refused invoices: correction, re-issuance, traceability. This is usually the weak link.
4. "Is the customer ICE a mandatory, validated field in your system?" If it is optional, you will discover the problem at the first wave of rejections.
5. "What is your plan for connecting to the DGI API?" The right answer describes an architecture ready to connect, not a connection already in place, since the official API is unpublished.
6. "How do you guarantee ten-year archiving?" A backup is not evidential archiving.
7. "What happens if the final specifications differ from your assumptions?" An honest answer exists: "we will adapt the connector." A promise of compliance already achieved against an unpublished standard is not one.

And the counter-question worth holding onto: no vendor can be "certified compliant" while the DGI has not published its API and final specifications. Any claim to the contrary is marketing, not compliance.

What if it all came out of your ERP already?

This article's logic leads somewhere simple: the XML format is only a system's output. If your invoicing data, customers, products and VAT already live in a properly configured ERP, producing UBL 2.1 becomes a connector question. If they live across three tools and two spreadsheets, the format will be the least of your concerns.

That is the subject of our guide to what is actually official on Moroccan e-invoicing, which places these technical requirements inside the regulatory timeline, separating, there too, verifiable facts from unsourced dates.

On implementation, our Moroccan localization work on Odoo is precisely about making PCGE, CNSS, CIMR, AMO and DGI requirements live inside the management system rather than in tools bolted alongside it. The complete Odoo Morocco guide sets out that approach.

Frequently Asked Questions

Which e-invoice format is mandatory in Morocco?

Available sources converge on two structured XML formats: UBL 2.1, an OASIS standard, and CII, a UN/CEFACT standard. UBL 2.1 is most often cited as the national platform's reference format. Since no definitive technical specification has been published in the Bulletin Officiel to date, these should be treated as the state of market consensus rather than as regulation.

Is an electronically signed PDF accepted?

No. A PDF, even signed, is not a structured format: its data is positioned for the human eye rather than exposed in machine-usable fields. The DGI platform has to check each invoice automatically, which requires XML. This is the gap most organizations underestimate.

Is PDF/A-3 required in addition to the XML?

That is contested. At least one Moroccan vendor presents XML + PDF/A-3 as a mandatory hybrid format, on the French Factur-X model. Other sources mention only UBL 2.1 and CII, with no PDF/A-3 requirement. Neither claim cites an official text. In practice, choosing a tool that can produce the XML and a readable representation covers both scenarios.

What is the difference between UBL 2.1 and CII?

They are two XML standards describing the same thing (an invoice) with different structures. UBL (Universal Business Language) is standardized by OASIS and widespread in Europe. CII (Cross-Industry Invoice) is standardized by UN/CEFACT. For a business the choice is the vendor's; what matters is that your system produces at least one of them correctly, from reliable data.

My current software exports XML: is that enough?

Not necessarily. "Exports XML" means nothing on its own: what counts is conformance to the UBL 2.1 or CII schema, with the right fields, identifiers and business rules. Ask for a sample file and have it validated against the schema. A homegrown XML export will not survive automated checking.

Where should I start if I don't know where I stand?

With your data, not your software. Check that your customers' ICE is present, unique and correct; that your product master data and VAT rates are clean; that your numbering is sequential and complete. These hold their value whatever format is ultimately retained and whatever date applies.