Reconciliation is not a monthly ritual here. Four pairs are computed from live records every time you open the screen, both sides shown, and the difference between them printed rather than buried.
A reconciliation that shows you only the answer is asking to be trusted. Each of these shows what was compared, what each side said, and what is left over.
Both sides are valued at weighted average, because that is what POS cost of goods posts at. Value the stock side at buying price instead and you report a variance that is only a difference of basis — a number that looks like a problem and is not.
Every purchase order that is neither paid nor cancelled, against what the payables account says you owe. A gap here is usually a receipt posted without its invoice, or an invoice entered against no order.
The internal-consistency test for double entry, run across every journal entry rather than a sample. Both halves are written on every posting, so the totals must match exactly; an imbalance means a journal was written incomplete.
Money actually leaving on the payment rails, against what the bank and cash accounts say left. Settled, pending and failed are counted separately, and the settled figure is split by what it was for and by how it was paid.
A total that agrees can still hide a gap, because two errors can cancel. So there is a second, narrower test on the one rail whose posting contract we own: a settled project payout is expected to carry its own settlement journal — debit payable, credit bank — keyed by the payment reference.
Any settled payout with no matching journal is listed by name. Money that left without reaching the ledger is the failure that costs most and shows least, because nothing on any screen looks wrong until someone goes looking.
That is the half that catches posting errors, unposted settlements and stock that drifted from its account — the errors made inside the system, which are the ones a system can reasonably be asked to find. The other half, your ledger against the bank’s own statement, is bank reconciliation, and it runs on its own screen.
On this page
Four ties between figures that are all inside AWRA, computed live every time the screen opens. Nothing is saved and nothing is locked; it is a view of the position now.
Its own screen
Bank reconciliation imports the statement — CSV, OFX or MT940, uploaded, emailed or fed in from M-Pesa — matches each line to the ledger, and completes and locks a statement date only when the two agree to the cent.
More we can add to your workspace
Settlement reports from the card acquirer read into bank reconciliation net of fees, so card collections clear against the ledger the way M-Pesa and bank statement lines already do. It is a well-defined build on rails that already exist, and we will scope it with a written specification, a timeline and a price.
Talk to us about itHelp Center
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
