The Charge Your Rate Field Cannot Hold
A fixed sum charged per document, and a turnover tax with a floor derived from floor area. Both are real obligations in Tunisia, neither is a percentage of a line, and a system built around a rate field has nowhere to put either.
The companion piece to this one is about a tax charged on a base that contains another tax. This one is about two obligations that are not charged on the line at all. One is a fixed sum attached to the document; the other is a percentage of the period, with a minimum computed from the size of your building. Neither can be expressed as a rate, and the ordinary consequence is that both end up somewhere nobody chose.
The stamp duty on an [invoice](/glossary/invoice)
Tunisia levies a stamp duty per invoice. Not a percentage of the invoice — a fixed sum, with a step for large retail establishments where the amount depends on which band the invoice value falls in. We are deliberately not printing the current figure: it moved in the 2023 finance law and again in the 2026 one, and a number here would be wrong within a finance law while adding nothing to the argument. Your accountant has the schedule.
What matters for software is the shape rather than the amount, and the shape has three awkward properties.
- It does not scale with the line. A hundred-dinar invoice and a hundred-thousand-dinar invoice can carry the same charge, so nothing about the amount predicts it.
- It attaches to the document, not the transaction. Split one order across three invoices and you owe three. Consolidate three deliveries onto one and you owe one. The obligation is a function of your own documentation habits.
- Where the stepped schedule applies, it is a step function of the value rather than a proportion of it — so it is a lookup, not a multiplication.
The obligation is a function of how many documents you issue, which means an invoicing policy is a tax decision and almost nobody treats it as one.
Where it goes when nobody decides
On a purchase invoice, the stamp duty is part of what the document cost you. It is not recoverable by any mechanism, so it belongs in the cost of what you bought — the same destination as any other unrecoverable charge on an import file.
What normally happens instead is that it goes into a general expense account, because there is no field for it. And an expense account collecting small unattributable amounts has a specific pathology: it grows, nobody can explain any individual entry in it, and the unit cost of everything the charges related to is understated by the same total. The money is not lost. It is just recorded in a place where it can never be attributed to a decision.
Where the charge belongs
- On a purchase: in the cost of the goods, alongside freight, clearing and any unrecoverable levy.
- It makes the unit cost true, which makes the margin true.
- It survives to the point where somebody prices the item.
- It is attributable — you can say which purchase caused it.
- It makes an invoicing policy visible as a cost, which is the only way it gets reviewed.
Where it usually goes
- Into miscellaneous expenses, or into the tax figure, or nowhere.
- Unit cost is light by the total, so gross margin reads high.
- It hits the period rather than the goods, so it never reaches a price.
- The account is a pool. No entry in it can be traced to a purchase.
- The invoicing policy is invisible, so nobody ever asks whether three invoices were necessary.
The other one: a tax on the period, with a floor from the floor
TCL is charged at 0.2% of local turnover and 0.1% of export turnover, with a minimum computed from floor area. Read that twice, because the last clause is the interesting one: the floor of the liability is a function of the building, not of the trade.
That makes it a genuinely different animal from everything else on a Tunisian transaction. There is no document to put it on. There is no line it attaches to. It cannot be charged to a customer, because it is not a tax on a sale — it is a tax on having traded, over a period, from premises of a certain size. Two businesses with identical sales can owe different amounts because one has a larger shop.
The software consequence is narrow and worth stating plainly, because the temptation is to overpromise here. An operations system cannot compute this and should not try. What it can do is hold the input: turnover for the period, split between local and export, because the two attract different rates and the split is the only part of the calculation that lives in your transaction records rather than in your lease.
| Obligation | What it is a function of | Who computes it |
|---|---|---|
| Stamp duty on invoices | The number of documents issued, and which band each falls in | Your system, if it can hold a per-document charge. Otherwise a person. |
| TCL | The period's turnover, split local and export, with a floor from floor area | Your accountant. Your system supplies the turnover split and nothing else. |
| FODEC | The net amount, where the product is in scope | A rate field can do this one — see the companion piece on the base it then feeds into. |
| VAT | The net amount plus the FODEC, where FODEC applies | A rate field cannot, because the base is not the line. |
The pattern behind both
These two obligations look unrelated and they fail for the same reason. Both are charges whose base is not the amount on the line: one is based on the existence of a document, one on the aggregate of a period. A finance system built around "rate × line" has a field for neither, so both get keyed as something else — a charge line, an expense, a manual journal — and the record of what caused them is lost at the moment of entry.
This is the general form of the problem, and it is worth carrying to any market: ask what each obligation is a percentage of, and notice the ones that are not percentages at all. Those are the ones that will end up in a miscellaneous account.
- Can a fixed charge per document be recorded so that it lands in the cost of the purchase, rather than in a general expense account?
- Is there a report of how many purchase and sales documents you issued in a period, which is now a cost driver rather than a volume statistic?
- Is turnover reportable split between local and export, from stored data rather than by filtering a spreadsheet?
- When an unrecoverable charge arrives on a later invoice, can it still reach the consignment it belongs to?
- Is there anything in your chart of accounts that is a pool of small unattributable amounts, and has anybody looked at what is in it?
What we can and cannot do with either of these
A fixed charge on a purchase can be carried so that it lands in the cost of the goods — that is what landed cost is for, and it is the right destination. What the product cannot do is compute the amount, because a stepped fixed sum is a lookup against a schedule that changes with each finance law, and we do not maintain Tunisian schedules. TCL we do not touch at all beyond holding the turnover split. Both of those are honest limits rather than gaps we are working on, and neither is the reason to buy or not buy: the reason is whether a charge that nobody can compute automatically still ends up attached to the thing that caused it.
A fixed charge attached to a consignment
Any charge, at any amount, attached to the purchase it belongs to and folded into the unit cost — including one that arrives on a separate invoice weeks later.
Turnover reportable split by local and export
The one input to TCL that lives in your transactions rather than your lease, available as a filter rather than a reconstruction.
Document counts as a reportable figure
How many purchase and sales documents were issued in a period, which becomes a cost driver the moment a fixed per-document charge exists.
Computing a stepped fixed duty from the current schedule
Not built and not planned. The schedule is a legislative lookup that moves with each finance law, and maintaining it for a market where we do not file is not a promise we would keep.
Computing or filing TCL
Not built. A turnover tax with a floor derived from floor area is your accountant's calculation, and no part of it is an operations question.
The verdict
The obligations that damage a set of books are rarely the big ones. They are the ones with no field: a fixed sum per document, a percentage of a period, a floor derived from a building. Each is individually small, each ends up in a pool nobody can explain, and together they understate the cost of everything they should have been part of. The fix is not a tax module — it is insisting that every charge, however odd its base, attaches to the transaction that caused it. Then a per-document duty becomes an argument about how many invoices you issue, which is a decision somebody can actually make.
What is not built for Tunisia today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Tunisia. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a compounding tax base, El Fatoora clearance, TEJ declarations, a French or Arabic interface, a bank or mobile money feed, a statutory return format or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
The base before the pipeline, in that order
Two builds, and the smaller one has to come first. The arithmetic: a tax base that can contain another levy, so FODEC at 1% of the net and VAT at 19% of the net plus the FODEC produce 201.900 on a thousand rather than the 200.000 our totals return today by adding the two rates — with the two amounts separated on the document and on the return rather than blended into one figure. Then the pipelines, and there are two of them: El Fatoora clearance through Tunisie TradeNet in TEIF XML with signature and QR code, and TEJ withholding declarations in XML. We would build them in that order, because a cleared invoice carrying a total that is short by 19% of the FODEC is worse than no clearance at all.
French and Arabic interface, banks and payments
Interface text and document templates in French, or in Arabic with right-to-left layout, plus bank feeds and local payment gateways wired into the Payments Register — with withholding decided at settlement rather than at invoicing, because the threshold is measured per payment.
Payroll and statutory returns
A Tunisian payroll engine with income tax bands, CNSS contributions and the TFP and FOPROLOS levies calculated on live employee records, producing declarations in the layout the administration expects rather than rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedBring one purchase with every charge on it
Freight, clearing, an unrecoverable levy and a fixed duty on the document. We will show you where each one lands and what the unit cost does when they all arrive.
Talk to us about landed cost