Electronic Invoicing in Tunisia: How TTN's El Fatoora Works and How to Integrate It

If your company sells to the Tunisian state or is growing past a certain size, sooner or later someone — your accountant, a public-sector client, a tender document — will mention El Fatoora, the electronic invoicing platform operated by Tunisie TradeNet (TTN). Most business owners discover it under deadline pressure, which is the worst way to discover an integration project. This guide explains what the system is, how the technical integration actually works, and where projects typically get stuck.

What is El Fatoora and who operates it?

El Fatoora is Tunisia's national electronic invoicing platform, operated by Tunisie TradeNet (TTN) — the same public operator that runs Tunisia's trade and customs data interchange. In this system, an electronic invoice is not a PDF sent by email: it is a structured, electronically signed document submitted to TTN, which validates and registers it.

The key ideas to understand:

• An e-invoice in the legal sense is a structured file (an XML document following the Tunisian specification), not a scan or a PDF attachment.
• The invoice is electronically signed with a certificate, which guarantees who issued it and that it has not been altered.
• TTN acts as the trusted third party: it receives the invoice, checks it, registers it and makes it available to the recipient, giving the document its legal weight.
• Registered invoices are archived in the system, which matters for audits and tax control.

If you have only ever emailed PDF invoices, the mental shift is this: with El Fatoora, the reference copy of the invoice lives in a government-operated system, not in your outbox.

Who is required to use electronic invoicing in Tunisia?

E-invoicing obligations in Tunisia have generally targeted large companies and suppliers invoicing the state and public entities (B2G), with the scope defined by finance laws and their implementing texts. The scope has evolved over the years and may widen further — so verify your exact situation with TTN and your accountant before deciding you are (or are not) concerned.

Practical guidance on scoping:

• If you sell to ministries, public agencies or state-owned enterprises, assume e-invoicing will be required or requested, and confirm the current rules for your case.
• If your company is classified among large taxpayers (for example, under the Direction des Grandes Entreprises), the obligation has generally applied — again, confirm the current thresholds with your accountant.
• If you are a small B2C business, you may not be obligated today — but a public-sector contract can change that overnight, and tenders sometimes require e-invoicing capability as a condition.
• Obligations, thresholds and penalties are legal matters that change with each finance law. Nothing in this article is legal or tax advice; TTN and your accountant are the authoritative sources.

How does the integration work technically?

Technically, integration means producing an invoice as a structured XML file in the Tunisian electronic invoice format, signing it electronically with a qualified certificate, and transmitting it to TTN — either manually through the El Fatoora web portal or automatically from your ERP or billing system via TTN's exchange mechanisms. TTN validates, registers and returns a reference.

The typical flow, end to end:

• Enrollment: your company signs up with TTN for the e-invoicing service — a contract and administrative file, not just an account creation.
• Electronic certificate: invoice signing requires a certificate from Tunisia's national certification authority (TunTrust / ANCE). Acquiring it involves an application, identity verification and, in most setups, a signing device or token.
• Invoice generation: your billing system produces the invoice in the required XML structure — the Tunisian specification defines the layout, mandatory fields (fiscal identifiers, line details, taxes) and encoding rules.
• Signature: the XML is signed with your certificate, making it tamper-evident and legally attributable.
• Submission: the signed invoice goes to TTN — manually via the portal for low volumes, or through system-to-system exchange (the integration an ERP connects to) for automated flows.
• Validation and registration: TTN validates the document, registers it and assigns it a reference; rejected invoices come back with errors to fix.
• Delivery and archiving: the recipient can retrieve the invoice through the system, and the registered document is archived.

For a developer, the honest summary is: this is a document-format-and-PKI project, not a REST-API-with-nice-docs project. The difficulty is rarely the transport; it is producing exactly correct, validly signed XML from your real billing data.

What are the common blockers in El Fatoora projects?

The blockers we see most: the certificate takes longer than planned, the ERP cannot export the required XML without custom development, invoice data is dirtier than anyone admitted (missing tax IDs, malformed fields), and nobody owns the rejected-invoice workflow. None of these are exotic — but each can stall a project for weeks.

In more detail:

• Certificate lead time: the TunTrust certificate application, identity checks and token setup sit on the critical path. Projects that start the paperwork on day one save themselves the classic last-month panic.
• ERP gap: most off-the-shelf or legacy ERPs used in Tunisia do not natively produce the Tunisian e-invoice XML. Expect a connector: extract billing data, map it to the specification, validate, sign, submit.
• Data quality: the XML specification is strict where your database is loose. Missing matricule fiscal values, free-text addresses, inconsistent tax codes and rounding differences between your ERP's totals and the recomputed line sums all surface as rejections.
• Signature plumbing on servers: signing with a token/certificate in an automated pipeline (no human clicking) requires careful engineering — secure key handling, signing service design, and a decision about where the certificate lives. This is where security shortcuts get taken and should not be.
• No rejection workflow: some invoices will bounce. Someone must see the error, fix the data and resubmit — define that loop before go-live, not after.
• Archiving discipline: keep your own signed copies and acknowledgments, organized and backed up. Your archive is part of your audit defense — and a backup only counts if you can restore it, as we argue in backups you can restore.

How should you architect the connector between your ERP and TTN?

Build a small, dedicated integration service between your billing system and TTN rather than hacking submission logic into the ERP itself. The service takes validated invoice data, generates and signs the XML, submits it, tracks status, and stores every artifact — giving you one place to log, retry, monitor and audit.

The architecture that has served our clients well:

• Extraction layer: pulls finalized invoices from the ERP or billing database — never drafts.
• Validation layer: checks mandatory fields (fiscal IDs, tax breakdowns, totals consistency) before signing; catching errors locally is faster than collecting rejections.
• Generation and signing: builds the specification-compliant XML and applies the electronic signature in a controlled component with strict access to the certificate.
• Submission and status tracking: sends to TTN, records the returned reference or the rejection reason, and retries transient failures idempotently — one invoice must never be registered twice because of a retry.
• Operational dashboard: a simple screen showing submitted / registered / rejected counts, so accounting sees problems the day they happen.

Two non-functional points deserve emphasis. First, security: the signing certificate is a company-critical secret — compartmentalize it, restrict access, and monitor its use. Second, personal data: invoices carry client identifiers and amounts, which brings Tunisian data-protection duties under the INPDP into play; our data protection checklist for SMBs covers the practical baseline, and the INPDP can confirm formal obligations.

Portal entry or full integration: which mode fits your volume?

For a handful of invoices per month, manual entry through the El Fatoora portal is generally the rational choice — no development, minimal cost. Past a few dozen invoices monthly, or when invoices originate in an ERP anyway, system-to-system integration pays for itself quickly in avoided re-typing, fewer errors and same-day registration.

A simple decision frame:

• Low volume, simple invoices: use the portal; train one accounting person as backup for the primary operator.
• Growing volume or public-sector tenders: plan the connector now; build it against a subset of invoice types first (your most common template), then extend.
• High volume or multiple entities: full automation with the dashboard and rejection workflow described above; manual entry does not scale and re-typing introduces the very errors that cause rejections.

How Innovation T helps

Innovation T builds the bridge between your billing reality and TTN's requirements: we audit your invoice data, develop the ERP-to-El Fatoora connector (XML generation, electronic signature handling, submission, rejection workflow), harden the signing infrastructure, and stay alongside your accountant and TTN during enrollment and testing. You get compliant invoices flowing automatically — with logs, monitoring and an archive you can defend in an audit.

Facing an e-invoicing requirement — or a tender that demands it? Contact our team and we will scope your El Fatoora integration in one working session.

FAQ

Is electronic invoicing mandatory for all Tunisian companies?

No — obligations have generally targeted large companies and suppliers invoicing the state and public entities, as defined by successive finance laws. The scope has evolved and may widen. Because thresholds and rules are legal matters that change, verify your company's exact situation with TTN and your accountant rather than relying on any article, including this one.

Is a signed PDF invoice the same as an El Fatoora e-invoice?

No. In the Tunisian system, the electronic invoice is a structured XML document, electronically signed and registered with TTN, which acts as trusted third party. A PDF — even signed — emailed to a client does not go through that registration. The registered document in the TTN system is what carries the legal weight for concerned transactions.

How long does an El Fatoora integration project take?

It depends on your ERP and data quality, but the pattern is consistent: administrative enrollment and the TunTrust certificate often drive the calendar, while connector development — extraction, XML generation, signing, submission, rejection handling — typically takes a few weeks of focused engineering. Starting the paperwork and certificate application on day one is the single best way to shorten the project.

Can my existing ERP send invoices to TTN directly?

Usually not out of the box. Most ERPs used by Tunisian SMBs do not natively produce the Tunisian e-invoice XML or handle the signature and submission flow, so a connector is developed alongside the ERP: it extracts finalized invoices, validates the data, generates and signs the XML, submits to TTN and records the result. Some local ERP vendors offer modules — ask yours first.

What happens if TTN rejects an invoice?

The submission comes back with a rejection reason — typically a format issue, a missing mandatory field or an inconsistency in identifiers or totals. The invoice must be corrected and resubmitted. This is why a defined rejection workflow matters: someone must see the error quickly, fix the source data and resubmit, and your integration should log every attempt so accounting can reconcile confidently.