A Credit That Reads as Cash
Apply a credit note to an invoice here and the invoice's amount-paid figure goes up by the credited amount. The invoice status says credited rather than paid, so the document is honest. The column is not, and anything measuring collections from it reads a credit as money received.
The finding, stated first
Applying a credit note increases the invoice's amount-paid figure. The invoice status distinguishes it correctly — credited, or partially credited, never paid — so the document tells the truth. Any figure built from the amount-paid column does not. Reconcile collections from the payments register rather than from invoice amounts, and treat credit notes as a separate line in every cash report you build.
A credit note reduces what a customer owes you. A payment reduces what a customer owes you. They are the same arithmetic and they could not be more different commercially: one is money arriving, and one is money you have decided not to ask for.
In our data, applying a credit note does something specific and worth knowing exactly.
What the application does
Three fields on the invoice change. The balance due goes down by the credited amount. The status becomes credited, or partially credited if something is still outstanding. And the amount paid goes up by the same figure.
The credit note is marked applied, linked to the invoice, and stamped with the date.
The status field is the part that is done right, and it deserves saying before the criticism. An invoice settled by a credit is not marked paid. It is marked credited, and the distinction is preserved permanently on the document. Anybody reading the invoice knows what happened to it.
The document is honest. The column is not. Which of those two your reporting reads decides whether your cash-in figure is right.
Where the figure goes wrong
Anywhere that sums the amount-paid column as a measure of collection.
One month, one credit note
Note what is NOT wrong. The balance due is correct, the ageing is correct, and the invoice status is correct. The error is confined to one column and to anything that reads it as a proxy for collection.
The second half: the ledger
Credit notes do not post to the ledger. Applying one updates the invoice and nothing else.
So the receivables control account in the ledger and the sum of outstanding invoices diverge by the total value of credits applied. Both are internally consistent; they are measuring different things and one of them has not been told about the credits.
This one is unpatched on purpose rather than by neglect, and the reason is worth understanding: posting a credit note correctly requires deciding which accounts it hits — a reversal of revenue, a contra-revenue account, or something else — and that is a chart-of-accounts decision rather than an engineering one. Making it wrong quietly would be worse than leaving it unposted visibly.
What a credit note can and cannot say
One more thing worth knowing while you are here, because it shapes how you should use them.
A credit note is a customer, an invoice, a number, an amount, a reason and two dates. It has no lines, no tax split and no currency of its own. So a credit that relates to three lines on an invoice, at two tax treatments, is one figure with a sentence of explanation.
For a full cancellation that is adequate. For a partial credit on a mixed-rate invoice, the tax consequence is something your accountant works out from the reason field.
Why an operation with more than one unit of account cannot absorb this
A Lebanese business that prices, collects and reports across more than one unit of account lives or dies on the accuracy of a single figure: how much actually came in, in what, and when.
Every other number can be reconstructed later. Cash-in cannot, because the moment passes. An overstated collections figure in that context is not an accounting inconvenience; it is a treasury decision made on a number that was forty thousand too high.
And the direction of the error is always the same. Credits inflate collections; they never deflate them. So the bias is consistently optimistic, which is the worst kind of bias to have in a cash figure.
What AWRA OpsHub does today
- Credit notes against a customer and an invoice, with a number, an amount, a reason, an issue date and an applied date.
- Application reducing the invoice balance correctly, and setting a distinct status — credited or partially credited, never paid.
- A check that the credit is applicable to the invoice before it is applied, and a cap at the outstanding balance.
- The credit note itself marked applied and linked to the invoice it settled.
- A payments register spanning the product, which is the correct source for a collections figure.
What it does not do
- Any ledger posting for a credit note. The receivables control account and the invoice list diverge by the credited total.
- Any separation between credited and paid in the amount-paid column — applying a credit increases it.
- Lines on a credit note, a tax split, or a currency of its own.
- Transmission of a credit note to any tax authority integration.
- A debit note entity of any kind.
Not ours, by choice
- The invoice status is correct and permanent. This is not a case of the product hiding what happened; it is one column carrying two meanings.
- The unposted ledger entry is a deliberate hold pending a chart-of-accounts decision, not an oversight. Posting it wrongly would be harder to unwind than leaving it visible.
- Nothing here is Lebanese. It is one column with two meanings; operating across more than one unit of account is where a wrong cash figure costs the most.
What is not built for the Gulf 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 Gulf. 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 tax authority pipeline, an Arabic 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.
Tax authority pipelines and VAT output
Electronic invoicing against your authority's published interface or its accredited-provider network, with retries, a failure queue and a daily report of sales carrying no registration identifier. The regimes here are at different stages, so this is one build per country rather than one build for the region — and we will say so rather than sell a GCC integration that does not exist.
Arabic interface, banks and acquirers
Arabic interface text with right-to-left layout and bilingual document templates, plus bank statement feeds, card acquirer settlements and instant-payment files wired into the Payments Register.
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
Wage protection files in the layout your ministry or free zone authority expects, with end-of-service gratuity accrued on live employee records rather than estimated once a year.
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 credit notes in any system
Apply a credit note. Show me every field that changes.
A good answer sounds like
Balance, status — and nothing that means "paid".
What it actually means
Ask to watch the save. Ours increases amount paid, and you would not learn that from any screen.
Does a credit note post to the ledger?
A good answer sounds like
Yes, to named accounts.
What it actually means
Ours does not, deliberately. Either answer is workable; not knowing means your control account and your invoice list disagree and nobody knows why.
Can a credit note carry lines and tax?
A good answer sounds like
Yes, mirroring the invoice.
What it actually means
A single amount is adequate for a full cancellation and not for a partial credit on a mixed-rate invoice.
Where should I read collections from?
A good answer sounds like
A payments source, not an invoice column.
What it actually means
The most useful answer on this page, and it applies to every system: read cash from where cash is recorded.
Check where your collections figure comes from
If any report you rely on sums invoice amounts paid, it includes your credit notes. Five minutes with your month-end pack will tell you whether that is happening. We will look at it with you.
Check the reportsFrequently asked questions
Is the invoice wrong?
No. The balance due is right, the ageing is right, and the status says credited rather than paid, permanently. The problem is confined to the amount-paid column and to anything that treats that column as a measure of cash received.
How do I get a correct collections figure?
Read it from where payments are recorded rather than from invoices. The payments register spans the product and only contains money movements, which is exactly the property you need. Then show credit notes as their own line in the pack, because they are a real number your management should see separately anyway.
Why has the ledger posting not been fixed?
Because it needs a decision about which accounts a credit note hits, and that is a chart-of-accounts question rather than an engineering one. Posting it to a plausible account without that decision would produce a ledger that balances and is wrong, which is harder to find and harder to unwind than a gap you can see.
