Guides

Morocco invoicing API: issue compliant invoices from your application

Your SaaS, CRM or e-commerce platform serves Moroccan customers, and they need compliant invoices. Building a Moroccan invoicing module yourself is a project of its own — legal mentions, numbering, VAT, tax regimes, upcoming e-invoicing. Here is what the law requires, the technical options that actually exist, and how a dedicated invoicing API reduces the whole thing to one HTTP call.

Why Moroccan invoicing cannot be improvised

A valid Moroccan invoice is not just a PDF with a total. Article 145 of the General Tax Code imposes a precise list of mentions: the issuer’s ICE and tax identifier, professional tax number, the customer’s ICE in B2B, VAT itemised by rate, the amount written out in words, and a continuous chronological numbering sequence with no gaps. An incomplete invoice can be refused by the customer and rejected in a tax audit.

On top of that come the special regimes: an auto-entrepreneur (law 114-13) invoices outside the scope of VAT with a mandatory mention; an exempt company carries a different mention; VAT rates were narrowed to 20% and 10% in 2026. And mandatory e-invoicing (a pre-clearance model) is arriving in waves — every invoice will have to pass through the national platform.

For a software vendor whose core business is not invoicing, keeping all of this current through every finance law is a recurring cost, not a one-off build. It is exactly the kind of building block you delegate.

The three technical options, compared

An integrator who must produce Moroccan invoices from their application has three paths.

OptionInitial effortComplianceMaintenance
Build your own module (in-house PDF generation)Weeks to monthsYours to carry, at every finance lawPermanent: rates, mentions, e-invoicing
Generic international PDF generatorDaysNone: no ICE, no Moroccan VAT, no legal numberingLow, but the output is not a compliant invoice
Moroccan invoicing API (Fatora)One hour — one HTTP callCarried by the API: article 145 mentions, regimes, current ratesNone on the integrator’s side

The often-forgotten point: numbering. A gapless FAT-2026-0001, 0002, 0003 sequence belongs to the merchant, not to your application. A serious multi-tenant API keeps one sequence per account — that is what makes the document legally enforceable.

How the Fatora API works

Every Fatora merchant has a personal API key, obtained by writing “api” to their WhatsApp bot. Your application stores that key and issues on their behalf: the invoice comes out in THEIR numbering, with THEIR stamp, THEIR logo and THEIR tax regime — which your code does not even need to know, the API enforces it by itself.

One POST /v1/documents call with the customer and the line items is enough: the API computes VAT, generates the PDF, and delivers it by WhatsApp, email or through a QR code to display or print. Modification happens in free text: your user writes “replace the training with 3 days at 1200 dh” in a text field, and the AI applies the correction on the same invoice number.

The full documentation, with production-tested examples for every endpoint, is on the site’s API page (see the “API” menu). Everything is included in the merchant’s plan, from the free trial — quotes do not even consume the quota.

Who benefits from integrating an invoicing API

The use cases keep coming back to the same profiles:

  • Moroccan SaaS and CRM vendors: an “Invoice” button in your interface, compliance included, without writing the module.
  • E-commerce platforms and marketplaces: an automatic invoice with every order, delivered by email or a QR code on the delivery note.
  • Web agencies: offer compliant invoicing to your merchant clients without developing or maintaining anything.
  • Vertical ERPs (transport, construction, distribution): your users invoice from the business tool they already have.
  • Point-of-sale software: receipt + invoice QR code printed together — the customer scans and leaves with their invoice.

What about mandatory e-invoicing?

This is the decisive argument for delegating rather than building. When the national pre-clearance platform activates your customers’ segment, every invoice will have to be transmitted in a structured format and validated before being enforceable. If your application generates its own PDFs, that connection will be your project. If it goes through an invoicing API, the API provider connects — once, for all its integrators.

Issuing structured, complete, properly numbered documents through an API today is precisely the state you want to be in on the day the switch arrives.

Frequently asked questions

How much does integrating the Fatora API cost?

Nothing for the integrator. The API is included in every Fatora plan, free trial included. Each merchant pays their own subscription (from 30 MAD/month) and API invoices count in their quota; quotes are free and unlimited.

Does my application have to handle VAT rates and tax regimes?

No. The merchant’s tax regime (normal, auto-entrepreneur, exempt) is stored on their Fatora account and enforced by the API: an auto-entrepreneur will always get invoices without VAT and with the legal mention, whatever your application sends. You can still set a rate per line if needed.

How does the end customer receive the invoice?

Three channels, combinable: WhatsApp (the PDF lands in their conversation), email (a message with the invoice attached), or QR code (every document exposes a PNG image to display at the counter or print — the customer scans and downloads). A lost document is resent in one call.

Does it work with a foreign product that has nothing Moroccan in it?

Yes — that is the typical use case: the foreign software keeps its business logic and calls the API when invoicing a Moroccan customer. All the local compliance — mentions, numbering, VAT, document language — is carried by the API.

This guide sets out the general framework applicable in Morocco. It does not replace advice from your accountant or the texts published by the Directorate General of Taxes.