ICE, Archiving and Integrity: Is Your Data Ready?
E-invoicing in Morocco: why the ICE becomes blocking data, what 'integrity-preserving retention' means next to a plain backup, and how to audit your own data before choosing software.
What breaks first is not the software. Most companies approach electronic invoicing as a tooling problem: which solution to buy, which format to produce. In practice, the first wall you hit in a real deployment is somewhere else, in the data. A missing customer ICE, loose product master data, a numbering sequence with gaps: these flaws are invisible today because a human catches them, and blocking tomorrow because a platform will reject them automatically. This guide covers what the reform demands of your data, and how to check it yourself before committing a budget.
Why the ICE stops being an administrative field
The ICE (Identifiant Commun de l'Entreprise) already appears on your invoices. What changes with electronic invoicing is its status: it goes from printed mention to structured data checked by a machine.
In a structured invoice file, the ICE of both issuer and recipient occupy identified fields. The DGI platform reads them, checks them, and rules. Since Morocco has adopted a pre-validation model, the consequence is blunt: an invoice with a missing or wrong recipient ICE is not an imperfect invoice to be tidied up at the next reconciliation. It is an invoice that does not legally exist until validated.
In operational terms: your ability to invoice a customer becomes dependent on the quality of that customer's record in your system.
That is a change of nature which most available content mentions in a single line, even though it represents the bulk of the preparation work in an SME that has been invoicing for years.
Typical defects in a Moroccan customer base
In databases built up gradually, the same categories of problem recur:
| Defect | Why it goes unnoticed today | What it produces tomorrow |
|---|---|---|
| Missing ICE on legacy customers | The invoice goes out anyway; nothing blocks it | Rejection at issuance |
| ICE entered as free text | No format or uniqueness check | Undetectable typos, intermittent rejections |
| Duplicate customers (same company, several records) | Each salesperson creates their own record | Inconsistent ICEs across records, fragmented history |
| Branch ICE vs head-office ICE | Little impact on paper invoicing | Wrong identifier transmitted, rejection or dispute |
| Individuals treated as companies | ICE field filled with a placeholder value | Check fails against invented data |
None of these is fixed by buying software. They are fixed by cleaning the database, work measured in weeks rather than hours, and useful regardless of any entry-into-force date.
Archiving: "backup" and "integrity-preserving retention" are not the same thing
The second underestimated subject is archiving.
Moroccan commercial law already requires ten-year retention of accounting records: that is not new with electronic invoicing. What the reform adds is that the object to be retained is no longer a paper file or a PDF, but the structured file itself, the one that carries legal weight.
The distinction that matters:
- A backup protects against loss. It answers: "can I restore my data after an incident?"
- Integrity-preserving retention protects against modification. It answers a different question: "can I demonstrate that this file has not been altered since it was issued?"
A company that diligently backs up its servers every night may satisfy no integrity requirement whatsoever, because nothing technically prevents retroactive modification of an archived file.
The precise technical arrangements the DGI expects (archive format, timestamping or sealing mechanisms) have not been published to date, the implementing decree still being awaited. What is certain is that the retention period will remain long and that the object retained must be the structured file. So you can prepare without knowing the details: know where those files will live, who can reach them, and how you would demonstrate they have not moved.
Numbering integrity
A third point, quieter but equally structural: sequence coherence.
A compliant invoicing system must produce traceable numbering, with no unexplained gaps and no retroactive reassignment. This is not a new requirement in itself (it is basic accounting practice) but automated checking makes it verifiable at scale, which human review only did occasionally.
The problematic habits are mundane: deleting an incorrect invoice instead of issuing a credit note, reusing a number "since that one was never sent", running parallel series per salesperson with no documented logic. All of them pass without consequence today. None will survive systematic checking.
The test you can run this week
You need no tool and no provider to find out where you stand. Export your customer base and the last twelve months of invoices, then answer six questions:
- What percentage of your active customers have an ICE on file? Below 100%, you have a quantifiable piece of work.
- Are those ICEs all correctly formatted, and unique? Sorting by ICE surfaces duplicates and outliers in minutes.
- How many records describe the same company? Sort by approximate legal name.
- Do your invoice numbers form a continuous sequence? Look for gaps and ask whether you could explain them to an auditor.
- Are your invoice lines free text or catalog references? Measure the share of free entry.
- Where do your issued invoices actually live? One system, or software plus spreadsheets plus a mailbox?
The outcome of that exercise is worth more than a quote: it tells you whether your problem is a tooling problem, or a data problem that the best product on the market will not solve for you.
The link to your management system
These three subjects (reliable identifiers, integrity-preserving retention, coherent sequences) share one trait: they are properties of the system your data lives in, not of an invoicing module bolted on top.
That is why the question "which e-invoicing solution should I buy" often arrives too early. If your customers, products, VAT and invoices already live in a single, properly configured system, compliance becomes connector work. If they live across several juxtaposed tools, no connector will reconcile what was never coherent.
The guide to UBL 2.1 and CII formats covers the other technical side of this, and our guide to what is actually official on Moroccan e-invoicing places the whole thing inside the real regulatory timeline, separating verifiable facts from the dates everyone repeats without a source.
On implementation, our Moroccan localization work on Odoo is precisely about making PCGE, CNSS, CIMR, AMO and DGI requirements live inside the management system itself.
Frequently Asked Questions
Why does the ICE matter so much under electronic invoicing?
Because its status changes. Today the ICE is a printed mention a human can correct if wrong. In a structured invoice it is a field checked automatically by the DGI platform, for issuer and recipient alike. Since Morocco has adopted a pre-validation model, an invoice with a missing or wrong ICE is rejected, so it has no legal existence until corrected and revalidated.
How long must electronic invoices be retained?
Moroccan commercial law already requires ten-year retention of accounting records, and that duration remains the reference. What is new is the object retained: no longer the paper or the PDF, but the structured file that carries legal weight. The precise technical arrangements the DGI expects (archive format, sealing, timestamping) have not been published to date, the implementing decree still being awaited.
Is a server backup enough to count as archiving?
No: these are two different needs. A backup protects against data loss and allows restoration after an incident. Evidential archiving protects against modification: being able to demonstrate that a file has not been altered since issuance. A company with flawless backups may satisfy no integrity requirement, since nothing technically prevents an archived file from being modified.
Can I still delete an incorrect invoice?
That is a habit to drop now. Accounting practice requires an issued invoice to be corrected by a credit note, not deleted, and automated checking makes sequence gaps visible at scale. Reusing a number because the invoice "was never sent" follows the same problematic logic.
Where do I start if my customer base is incomplete?
With a quantified assessment rather than a purchase. Export your base and measure: share of customers without an ICE, duplicates, malformed values, share of free text in invoice lines. That diagnosis takes a day, costs nothing, and determines whether your issue is tooling or data. The cleanup that follows usually takes weeks, which is why it is better started before the entry-into-force date is known.
Should I wait for the decree before acting?
No, and this is the central point: cleaning up customer identifiers, de-duplicating master data, correcting numbering and clarifying where invoices are stored all hold their value whatever timeline is ultimately set. They are also the slowest tasks. Waiting for the decree to begin them concentrates the slowest work into the shortest window.
By RMG Solutions
Certified Odoo Partner | Cybersecurity | Infrastructure | GRC
Last updated : July 26, 2026