Eight Columns on a Line
An invoice line has eight columns: the item, a description, a quantity, a unit price, a discount, a tax rate, a total and the invoice it belongs to. A per-line discount and a per-line tax rate are more than many systems offer. What is not there decides which questions you can ask.
The conclusion first
The line does discounting and tax properly, at line level, which is the part most systems in this bracket get wrong. It carries no unit of measure, no fractional quantity, no cost and no project — so a line cannot tell you its own margin, cannot express half a kilogram, and cannot be attributed to a job. Everything on this page follows from those four absences.
A sale is a header and some lines, and almost every interesting question about a sale is a question about a line. Which product, at what price, at what margin, to which job, in what unit.
It is worth knowing exactly which of those a line can answer.
The eight columns
The invoice it belongs to. The catalogue item. A description, which can differ from the item's name — useful, because the thing you are selling is not always described the way your catalogue describes it. A quantity. A unit price. A discount. A tax rate. And a line total.
Two of those deserve credit specifically.
The per-line tax rate means one invoice can mix treatments — a taxable line and an exempt line on the same document — which is ordinary in real trading and is not universally supported at this end of the market.
The per-line discount means a concession is recorded against the thing it was given on, rather than as a lump at the foot of the document. That is the difference between knowing you discounted and knowing what you discounted.
Tax and discount at line level. That is the half of this most systems in this bracket do at header level and call it enough.
What the line cannot carry
| Missing from the line | Consequence |
|---|---|
| A unit of measure | The line says 12. It does not say twelve of what — the unit lives in the item name, if anywhere |
| A fractional quantity | Quantities are whole numbers throughout the product; half a metre cannot be invoiced as half a metre |
| A cost | Margin per line is derived from the item master at read time, not stamped at sale |
| A project | Revenue cannot be attributed to a job at line level, although a whole invoice can carry one |
| A warehouse or location | Those are on the invoice header, so one invoice ships from one place |
The third row is the one that surprises people, and it is worth dwelling on because the product does the opposite thing correctly one module away.
The cost that is not stamped
When stock is issued to a project, the unit cost is stamped at the moment of issue and never recalculated — deliberately, because a finished job has to cost the same twice.
An invoice line does not do that. It carries what you charged and not what it cost you, so any margin figure is computed against whatever the item's cost is when somebody asks. Buy more of that item next month at a different price and the reported margin on a sale from March moves.
The direction is predictable: in a market where input prices rise, historical sales gradually look less profitable than they were reported to be at the time, because the cost they are measured against keeps climbing.
Nothing about the sale is wrong. The revenue is exactly right and permanent. It is the margin — a derived figure, not a recorded one — that moves, and knowing which of your numbers are recorded and which are derived is most of financial literacy in any system.
Why a Togolese trader meets the unit problem first
Because a corridor economy handling goods on their way somewhere else deals constantly in quantities that are weights and volumes rather than counts — and in the same catalogue as goods that genuinely are counted.
A line reading 12 with no unit is fine for cartons and useless for a commodity, and the invoice is the document where that ambiguity reaches your customer. They will read the number, apply their own assumption, and one of you will be wrong.
The workaround is the same one that applies throughout the product and it is worth repeating here because the invoice is where it becomes visible: put the unit in the item name, define everything in the smallest unit you transact in, and never let two sites adopt two conventions. The full argument is in A Quantity That Cannot Have a Decimal Point.
The line's free-text description helps here too, and it is the one place the product gives you room. A description reading "Maize, 50kg bags" on a line for 12 removes the ambiguity for the human reading it, even though nothing in the system understands it.
What AWRA OpsHub does today
- A per-line tax rate, so one invoice can mix taxable and exempt lines.
- A per-line discount, recorded against the line it was given on.
- A description per line that can differ from the catalogue item's name.
- A unit price, a quantity and a line total, with the document-level tax context frozen in a snapshot.
- A project and a warehouse on the invoice header, so a whole document can be attributed.
What it does not do
- Any unit of measure on a line, or anywhere else in the product.
- Fractional quantities. Every quantity column in the product is a whole number.
- A cost on the line, so margin is derived from the item master at read time rather than stamped at sale.
- A project, warehouse or location per line.
- A serial or batch reference on an invoice line.
Not ours, by choice
- Line-level tax and discount are genuinely good and are the part of this most often done badly elsewhere. The criticism is about what is absent, not about what is there.
- Revenue is recorded and permanent. Margin is derived and moves. That distinction is the useful thing to take away.
- Nothing here is Togolese. It is what a line without a unit does; a corridor economy mixing counted and weighed goods is where it shows up on a customer-facing document.
What is not built for the CFA franc zone 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 the CFA franc zone. 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 national e-invoicing pipeline, a French interface, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, 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.
National tax pipelines and a clean handoff to your ledger
Electronic invoicing against your administration's published interface, and a defined monthly export mapped to your expert-comptable's chart of accounts — with retries, a failure queue and a reconciliation report rather than a black box. The statutory ledger itself stays with them, by design; what we build is the pipe to it.
Mobile money, banks and French interface
Wave, Orange Money and bank statement feeds into the Payments Register, plus French interface text and document templates.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
National income tax and social security schedules produced in the layout your filing body expects, generated from live payroll records 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 integratedFour questions about an invoice line
Can two lines on one invoice have different tax treatments?
A good answer sounds like
Yes, per line.
What it actually means
Ours can. A header-level tax rate is the common shortcut and it makes a mixed invoice impossible.
Is the cost of sale stored on the line, or looked up?
A good answer sounds like
Stored at the time of sale.
What it actually means
Ours looks it up. That means historical margin moves when you buy again, which is a surprise if nobody told you.
Invoice half a kilogram. Show me.
A good answer sounds like
A decimal quantity.
What it actually means
A schema question, not a settings one. Ours is a whole number everywhere.
Where does the unit of measure appear on the printed document?
A good answer sounds like
A column.
What it actually means
Ours has no such column. It appears wherever you put it in the item name or the description.
Look at a real printed invoice before you decide
Ask any vendor for a PDF of a real multi-line invoice with mixed tax treatments and a discount. It answers more questions in thirty seconds than a feature list does in an hour.
See a real documentFrequently asked questions
How do I show a unit on an invoice?
In the item name or in the line description, both of which print. The description is the better place because it is per line and can be written for the customer reading it — "Maize, 50kg bags" beside a quantity of 12 removes the ambiguity even though nothing in the system understands it.
Why does my margin on an old sale keep changing?
Because the line records what you charged and not what it cost, so margin is computed against the item's cost at the moment you run the report. Buying the same item again at a different price moves the reported margin on historical sales. The revenue does not move; only the derived figure does.
Can one invoice cover two projects?
No. A project is on the invoice header rather than the line, so a document belongs to one job. Where a single customer needs billing for two jobs, the workable answer is two invoices — which is also cleaner for the customer receiving them.
