The Opening Balance That Never Closes
A customer record has a balance field. It is written only when somebody creates or edits the customer by hand — no invoice, payment or credit note ever touches it. And it is the opening balance of every statement you send and the base of every credit exposure you calculate.
There is a number on the customer record that two important calculations depend on, and it is a number a person typed.
What writes it, and what reads it
It is written in exactly two places, and both are the customer form: once when the customer is created, once when the customer is edited. It is validated as a number not less than zero. That is all.
No invoice increases it. No payment reduces it. No credit note adjusts it. Search the application for anything that increments, decrements or assigns it outside those two form handlers and there is nothing.
It is read in two places, and both matter.
It is the opening balance of the customer statement — the figure the running balance starts from before a single invoice or payment row is added.
And it is the base of the credit exposure calculation — the figure to which every open invoice is added before the total is compared to the credit limit.
Two calculations, one hand-typed anchor, and nothing in the running of the business ever touches it again.
The charitable reading, which is probably the right one
This is not a broken running balance. It is almost certainly a migrated opening balance: what the customer owed you before this system existed, carried in at go-live so that statements and credit checks are not blind to history.
On that reading the design is coherent, and adding open invoices on top of it is correct rather than double counting — the field represents pre-system debt and the invoices represent everything since.
We are setting that out first because it would be easy, and wrong, to present this as a bug. It is not. What it is, is a field whose correctness depends entirely on a convention that nobody is told about.
Where that goes wrong
Three ways, and all of them are about the convention rather than the code.
| What somebody does | What they expect | What happens |
|---|---|---|
| Types the current outstanding balance at migration, including invoices also loaded into the system | A correct opening position | The same debt is counted twice — once as the balance, once as the open invoices |
| Types a figure and never revisits it | It settles as the customer pays | It never moves. The statement opens from it forever, and it sits in every credit exposure permanently |
| Edits it later to "correct" the customer's balance | The statement will now be right | The statement changes and the invoices do not, so the two disagree from that point on |
| Leaves it at zero for a new customer | Nothing | Correct — this is the case the design handles cleanly |
The second row is the common one and the quietest. A pre-system debt that has since been paid — in cash, outside the system, in the first month — stays on the record as an opening balance forever. Every statement you send that customer opens with a number they settled two years ago, and every credit check counts it against their limit.
And the third row is the trap for whoever finds it. Somebody notices the statement is wrong, edits the balance to fix it, and has now made a change that the invoice list does not know about. The next statement is right and the credit exposure has silently moved.
Why an Algerian seller should check this early
Because migrations here frequently carry a long tail of legacy receivables from whatever came before — a ledger, a book, a set of spreadsheets — and the temptation at go-live is to get the customer's total right on day one by typing it in.
That is exactly the action that produces the first row of the table. If the open invoices are also being loaded, the balance field should be zero, and if only the total is being carried then no invoices should be loaded. Doing both feels thorough and doubles the debt.
The check is quick and it is worth doing whatever your migration did: pick five customers, compare the statement's closing balance against the sum of their outstanding invoice balances, and see whether the difference is the balance field.
What AWRA OpsHub does today
- A balance field on every customer, editable on the customer form and validated as a non-negative number.
- Statements opening from that balance and building a running balance from invoices and payments.
- Credit exposure computed as that balance plus every open invoice, evaluated at invoice creation and update.
- Payments recorded against specific invoices, with an ageing view of receivables.
What it does not do
- Any automatic maintenance of the balance field. No invoice, payment or credit note writes to it.
- Any reconciliation between the balance field and the sum of outstanding invoices.
- Any indication on the customer form that the field is an opening position rather than a live balance.
- A history of changes to the field, so an edit leaves no trace of what it was before.
Not ours, by choice
- Read as a migrated opening balance, the design is coherent and adding open invoices to it is correct. The problem is that nothing says that is what it is.
- For a customer created inside the system with the field left at zero, none of this applies and both calculations are exactly right.
- Nothing here is Algerian. It is what happens to a hand-typed anchor; a migration carrying legacy receivables is where it starts wrong rather than drifting.
What is not built for North Africa 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 North Africa. 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, an Arabic or 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.
Tax pipelines and declaration output
Electronic invoicing and declaration output against your administration's published interface, with retries, a failure queue and a reconciliation report rather than a black box.
Arabic and French interface, banks and payments
Interface text and document templates in Arabic with right-to-left layout or in French, plus bank feeds and local payment gateways 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
Income tax and social insurance 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 integratedOur position
Treat the balance field as a migration-only opening position and set it to zero for every customer created afterwards. If you are migrating, load either the opening balance or the open invoices — never both. And check five customers now: compare each statement's closing balance against the sum of their outstanding invoices, and if the difference is the balance field, you know what to do.
Three questions about any customer balance
What updates this balance?
A good answer sounds like
A named list of events, or an honest "only the form".
What it actually means
Ours is only the form. A field that looks live and is not is the single most common quiet error in a customer master.
Is it an opening balance or a running one?
A good answer sounds like
One word, and a label on the screen.
What it actually means
If the vendor has to think about it, the field is ambiguous, and an ambiguous field on a migration is a doubled debt.
Does credit exposure include it?
A good answer sounds like
A precise answer.
What it actually means
Ours does. A stale opening balance therefore consumes credit limit permanently, which is a customer service problem before it is an accounting one.
Check five customers this afternoon
Statement closing balance against the sum of open invoices, five times. If they differ by the balance field, your migration made a decision nobody wrote down. We will help you unwind it.
Run the comparisonFrequently asked questions
Should I set the balance to zero for all my customers?
For any customer whose full history is in the system as invoices and payments, yes — anything in that field is being counted a second time. For customers carrying genuine pre-system debt that was never loaded as invoices, no: the field is doing exactly the job it was designed for.
If I pay off a legacy balance, how do I clear it?
By editing the field on the customer form, which is the only thing that writes it. Do it deliberately, record why somewhere, and expect the credit exposure to move at the same moment — because that field is part of the exposure calculation.
Does this affect the ledger?
No. The field is on the customer record and is read by the statement and the credit check. It is not a posting, and the receivables control account is unaffected by it — which is another reason to treat it as a migration artefact rather than as an accounting figure.
