Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
For Tunisia
Where FODEC applies, the VAT is 19% of the price plus the FODEC rather than 19% of the price — so the tax on 1,000 dinars of goods is 201.900 and not the 200.000 that adding 19 and 1 produces. Then there is a stamp duty that is a fixed sum per document rather than a percentage of it, a local tax charged on the period rather than the sale, and a withholding whose threshold is measured per payment rather than per invoice. Five levies, five bases, three moments. Our own totals function adds rates, so it is wrong about this too, and the figure is below.
The regime, as a specification
Read the last column first. Every finance system ever sold assumes tax is one rate applied to one net amount at the moment an invoice is raised. That description fits exactly one row here, and it is the row nobody outside Tunisia has heard of.
A percentage of what
The selling price excluding VAT. Applies to a listed scope of products and services, at the industrial production and import stages — not to everything, and not at every stage.
Decided when
When the invoice is raised
The shape every system assumes
A percentage of the line.
A percentage of what
The selling price excluding VAT plus the FODEC. Where FODEC applies, the VAT base is larger than the net amount on the line by exactly the FODEC.
Decided when
When the invoice is raised
A shape no rate field holds
A percentage of a base that already contains another levy.
A percentage of what
The document. Not the amount on it, except insofar as the amount decides which step applies. We deliberately do not print the figure here — it moved in 2023 and again in 2026, and the structure is the durable part.
Decided when
When the invoice is raised
A shape no rate field holds
Not a percentage of anything. A charge per document.
A percentage of what
The period's turnover, with a minimum computed from floor area. The floor is a function of the building rather than of the sales.
Decided when
At the return, on the period
A shape no rate field holds
A percentage of a period, with a floor that ignores the sales entirely.
A percentage of what
A payment over TND 1,000 including VAT. The threshold is assessed per payment to the supplier, not per invoice, so three sub-threshold invoices settled together are over it.
Decided when
At settlement, after the invoice has gone
A shape no rate field holds
A percentage of a payment, decided by an event the invoice cannot see.
The pattern is the finding. No two of these five share a base, and they do not even share a moment — one is decided at production, three at invoicing and one at payment. A system with one tax field, one rate and one base is not slightly wrong here. It is wrong four times, in four different ways, and none of the four announce themselves.
Five checks against your own invoices, before you ask any vendor anything
Take one supplier invoice for a locally manufactured product. Multiply the pre-tax total by 0.19. Does it equal the VAT line?
If it does not, is the difference 19% of a 1% line called FODEC — and is that line in your unit cost or in a tax account?
Does your system decide withholding when the invoice is entered, or when the payment is made?
When you settle three small invoices in one transfer, does anything check the threshold against the transfer rather than against each invoice?
Where does the stamp duty on a purchase invoice land today — in the cost of the goods, in an expense account, or nowhere?
The arithmetic, and ours
Three decimal places because the dinar has three. The numbers below are a derivation from the two rates named above rather than a figure to be remembered — if either rate moves, so does this.
Net amount on the line
1,000.000
What you agreed to pay for the goods.
FODEC at 1% of the net
10.000
A percentage of the line. This part every system can do.
The base the VAT is charged on
1,010.000
Not the net amount. The net amount plus the FODEC.
VAT at 19% of that base
191.900
Not 190.000, which is 19% of the net.
Total consumption tax
201.900
Plus a stamp duty on the document, which is a fixed sum and not part of this sum at all.
What adding the two rates gives: 20% of 1,000.000
200.000
What Tunisia charges
201.900
The difference, which is 19% of the FODEC, every time
1.900
The product resolves the tax on a document by taking every tax type you have enabled and adding their default rates into one blended figure. Enable VAT at 19 and a second levy at 1 and it returns 20, labelled with both codes joined together and no split between them. On the example above that is 200.000 where Tunisia charges 201.900, and it is reached from twenty-one places in the codebase — invoices, quotations, point of sale, the vendor portal and the API. We measured this rather than reasoned about it, and there is a test in the repository that pins the behaviour so that fixing it has to be a deliberate act rather than an accident.
Two consequences, and the second is worse than the first. The blended figure under-states the tax by 19% of the FODEC on every affected line, which is small enough that nobody notices and systematic enough that it never cancels out. And because it is blended, there is no VAT amount to put on a return — one number arrives where two are needed. Neither is a configuration problem you can solve by choosing better settings, and both are reasons we are not the system that should be issuing your invoices in Tunisia.
What this costs today
None of these fail on the day they happen. Each is a number in the wrong place or decided at the wrong moment, which is the hardest kind of error to find because nothing about it looks like an error.
Where FODEC applies and the system charges 19% of the net, the VAT on the document is short by 19% of the FODEC. On one line it is a rounding-sized number. Across a year of production invoices it is a consistent, one-directional variance that nobody can trace, because everything about the calculation looks correct.
FODEC on a purchase is part of what the goods cost, and stamp duty on a purchase invoice is a cost of the document. Systems with one tax field put the first inside the tax and the second into a miscellaneous expense — so unit cost is understated and the expense account collects amounts nobody can attribute to a purchase.
The threshold is measured on the payment, not the invoice, and the deduction happens at settlement. A system that decides at invoice entry is wrong in both directions at once: it withholds on invoices that are settled below the threshold, and it misses transfers that clear three small invoices at once.
Withholding deducted from what you invoice is only creditable against a certificate, and from 2026 those certificates move through TEJ in XML. Where the certificate arrives by email and the receivable lives in the ledger, the two are never joined and the credit is unclaimable in practice.
The operation, in detail
Each links to a fuller tour. Nothing here clears an invoice through El Fatoora, produces a TEJ declaration, or computes a Tunisian tax total correctly where FODEC applies — the boundary is drawn in full below, and it was drawn above before this grid rather than after it.
FODEC on a purchase, the stamp duty on the document and any tax that is genuinely a cost attached to the consignment when the invoice arrives, with the unit cost recalculating. Which is the only way a charge that is not a percentage of anything ends up in the price of something.
Transfers, cash and card settlements in one place with the invoices each one clears. Where the threshold is measured on the payment rather than the invoice, a payment-level view is not a convenience — it is the only level at which the question can be answered.
The withholding certificate against the invoice it relates to, the suspension authorisation against the purchase it covers, the clearing paperwork against the consignment — previewable in place and retrievable by transaction rather than by whoever filed it.
A default rate per country that is yours to set and change rather than one regional assumption. Read the scope section below before you assume that covers Tunisia: it holds a rate, and Tunisia does not have a rate.
Project, site, cost centre and customer coded at entry rather than reconstructed at reporting time, which is what turns a per-contract or per-site total into a filter instead of an excavation.
For the export-facing half of this market, an invoice raised in euro and settled in dinar keeps both amounts and the genuine rate on the transaction, so a margin can be explained months later rather than recalculated from a rate nobody wrote down.
Scope, in three parts rather than two
Three columns, because "no" means two entirely different things and a single list hides which is which. The middle column is work that has not been done and has a price. The right-hand column is work we would decline from a paying customer — and it is the column you should demand from every other vendor on your list, because a page without one has not told you where its edges are. The first item in the middle is a defect in our own arithmetic rather than a missing feature, stated with the figure: a page that argues about tax bases and then hides its own would not deserve to be believed.
Running in the product today
On the roadmap — and commissionable now
Not ours, by choice — and this column is the reason to believe the other two
Nothing in the middle column is a permanent limit, and that is not a figure of speech. Kenya's eTIMS transmission and its maintained statutory payroll engine exist because Kenyan clients needed them and commissioned them — neither arrived by itself. If the compounding tax base, El Fatoora, TEJ output or a French interface is what stands between you and a decision, say which one and we will scope it as a build: written specification, timeline and price, before you commit to anything. What we will not do is print a date on this page that nobody has paid for.
Read the three columns rather than counting them. The middle one is work — and work has a specification, a timeline and a price. The right-hand one is where we stop on purpose, and it is the column worth demanding from every other vendor on your list, because a page with nothing in it has simply not told you where its edges are. A vendor claiming both halves here should be asked to compute 1,000.000 plus FODEC plus VAT in front of you and show you the split; we have published what ours does.
How this starts
Take a supplier invoice for a locally manufactured product, multiply the pre-tax total by 0.19 and compare it to the VAT line. If they differ by 19% of a 1% line, you have found the whole subject of this page using nothing but a calculator.
Not what they were, but which account holds them today. If FODEC is inside a recoverable tax figure and the stamp duty is in miscellaneous expenses, your unit cost is understated by a knowable amount and the fix is a coding decision rather than a software purchase.
Clearance, declaration output and payroll are local purchases and should be made locally — we have said so above with the arithmetic to back it. What is left is cost, evidence and control, and that is a smaller conversation than most vendors will let you have.
Read before you shortlist
Two levies at 19% and 1% are not a levy at 20%. Where one is inside the other's base the difference is small, one-directional and permanent — and almost every finance system computes it by adding the rates.
Three invoices below the threshold settled in one transfer are above it. Where withholding is decided at invoice entry the system is wrong in both directions at once, and the certificate that makes the credit claimable arrives later still.
Ask every vendor to compute 1,000 dinars plus FODEC plus VAT and show you the split. We publish what ours does, which is wrong, which is the only reason the question is fair.
Questions we are asked here
No, and the page has to tell you why rather than let you catch it. FODEC applies to a listed scope of products and services and only at the industrial production and import stages. An importer of finished goods for resale, or a business whose outputs are outside the listed scope, may never see a FODEC line — and for those transactions the VAT genuinely is 19% of the net and the ordinary arithmetic is correct. What the page argues is that the tax on a Tunisian document is not reliably one rate times one base, and that a system which assumes it always is will be wrong on the transactions where it is not. Check a locally manufactured product rather than a resale line; that is where the difference shows.
Not today, on two independent grounds, and either would be enough. The regulatory one: Tunisie TradeNet runs El Fatoora, a compliant invoice is TEIF XML carrying a signature and a QR code, and it is cleared before it is valid — already mandatory for business-to-government within the Large Enterprises Directorate and for medicine and fuel sales between professionals, and extended to service providers from 1 January 2026 by Article 53 of the 2026 Finance Law. We have no connection, no accreditation and no TEIF output. The arithmetic one: our totals add tax rates and Tunisia stacks them, so even a printed document would carry a total short by 19% of the FODEC with no VAT figure separated out. We would rather give you both reasons than the more flattering one. **Both are on the roadmap rather than boundaries, and both are commissionable now.** The compounding tax base first — that one we want to fix for every customer, not just for you — then El Fatoora clearance against the published TEIF specification. Kenya's eTIMS transmission exists because a Kenyan client needed it and commissioned it, and it is the only reason we can make this offer with a straight face: tell us this is what stands between you and a decision and we will come back with a written specification, a timeline and a price before you commit to anything. What we will not do is put a date on it today, because nobody has paid for one.
It can carry it as a charge on a purchase so that it lands in the cost of what you bought, which is where it belongs. What it cannot do is compute it, because it is not a percentage of anything: it is a fixed sum per invoice, stepped by invoice value for large retail establishments, and the amounts moved in the 2023 finance law and again in the 2026 one. We deliberately do not print the current figure anywhere on this page — it would be wrong within a finance law and it adds nothing to the argument, which is about shape rather than amount. Your accountant has the current schedule.
No — and unlike most of the other noes on this page, this one is a boundary rather than a backlog. TCL is 0.2% of the period's local turnover, 0.1% on export turnover, with a minimum computed from floor area: a tax on a period with a floor derived from your building. There is no document to put it on and no line to attach it to, so there is nothing for an operations system to be right or wrong about. What we hold is the turnover detail a return is built from, split between local and export, which is the one input that lives in your records rather than in your lease. **You should want that answer from a vendor.** A supplier who offers to compute a turnover tax with a square-metre floor is quoting for a calculation they will not maintain past the next finance law, and you will find that out in the year they stop.
The ceiling is 1.5% on payments over TND 1,000 including VAT, reduced to 1% or 0.5% depending on the payer's corporate tax bracket — so there is no single rate to quote and any vendor quoting one has not read the rule. Two details matter more than the rate. The threshold is assessed per payment to the supplier rather than per invoice, so three invoices below it settled in one transfer are above it. And it applies at settlement rather than at invoicing, so a system that decides at invoice entry is wrong in both directions. Our part is the payment register — the payment, the invoices it clears, the amount withheld and the certificate held against it. From 1 January 2026 the declaration itself goes through TEJ in XML for every company, and we generate nothing TEJ accepts.
Operationally, the thing that changes is that a document becomes load-bearing. Wholly exporting companies can acquire certain goods and services VAT-free under authorisation, and what a particular authorisation covers is in a document we have not read and will not characterise. The software consequence is narrow and real: the authorisation has to sit against the purchases it covers, and a purchase that should have been suspended and was taxed anyway becomes a claim that has to be evidenced. Both of those are document-against-transaction problems, which is a thing we do. Whether a given purchase is within your authorisation is a question for your adviser.
Not today. English interface, English documents, no right-to-left layout, support in English. We are raising it in the first paragraph of this page rather than burying it here, because in Tunisia it is frequently disqualifying — a finance team that files in French and Arabic will not accept an English-only ledger. **It is on the roadmap and commissionable now, and we would quote it as engineering rather than as a translation.** French is interface text and document templates; Arabic is that plus mirrored layout, numeral formatting and column order, which is engineering and gets priced as engineering. If it is what stands between you and a decision, ask us and we will come back with a written specification, a timeline and a price. And the honest caveat, since you will weigh it anyway: a local vendor who already ships in both languages starts from a position we would be building towards, so if language is your first requirement rather than your third, buying locally is the rational move and we would rather say so than win the month and lose the year.
Because of the item we volunteered rather than the ones we claimed. This page publishes a defect in our own tax totals, with the figure, the direction of the error and the number of places in the code it reaches, and there is a test in the repository pinning the behaviour so that fixing it has to be deliberate. That is the evidence on offer, and it is checkable in a way a reference story is not. The rest is ordinary: no office here, no implementation partner, remote support from Nairobi in English, two hours behind us. Ask us what happens when the person who implemented your system leaves — and ask the other vendors on your list to compute 1,000.000 plus FODEC plus VAT in front of you.
Take a supplier invoice for a locally manufactured product, multiply the pre-tax total by 0.19, and see whether it matches the VAT line. Bring the answer and we will tell you honestly which half of your problem we are for.