Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
A sale rings up. A payment clears. Stock leaves the store on an approved invoice. Payroll posts. In every one of those moments AWRA OpsHub writes both halves of the accounting entry — debit and credit, in the same breath as the operation — into a general ledger you can browse, drill into and trial-balance the same afternoon.
Journal entries · General ledger with running balances · Trial balance · Ten automatic posting routes · Mirrored on the API
Once in real life — a customer pays, a supplier is settled, stock moves, someone is paid — and then again, weeks later, when a bookkeeper opens a bank statement and tries to work out what all of it was. The second pass is where the errors live, because it is done from evidence rather than from the event: a reference on a statement line, a receipt in a drawer, somebody's memory of a Tuesday.
That gap has a cost you can measure. Margins look fine until the reconstruction finishes and discovers cost of sales was never relieved. Receivables look healthy because a credit sale increased cash the day the goods left. Output tax on a fulfilled invoice quietly never reaches a tax account, which is a filing problem rather than a presentation one. None of these announce themselves. Every one of them is invisible in an operational report and only ever visible in a ledger.
AWRA OpsHub removes the second pass by making the first pass accounting. There is exactly one service in the platform that is allowed to write to the ledger, and it physically cannot write one side of an entry on its own. Every operational routine that touches money calls it, hands it a debit account and a credit account, and gets a balanced pair back. The general ledger is therefore not a report assembled from your operations. It is your operations, expressed in accounts.
No queue to run, no "post to accounting" button, no nightly batch that can fail silently. Each of these operational events posts at the moment it completes, with the account pair its own logic determines.
Rings revenue and relieves inventory at cost in two balanced pairs, so gross margin is a ledger fact on the day of the sale rather than a month-end derivation.
Reverses in three conditional legs rather than one blunt one. Revenue always comes back. Cost only returns if the goods did — a written-off return leaves the cost consumed. And the refund only debits cash where a tender actually moved money.
When an approved issue is backed by a customer invoice, the invoice is the authority on all three figures — the agreed total, the discount already applied, and the tax split out. Receivables take the gross; revenue is credited net; tax gets its own line.
Clears the receivable the sale created and lands the money in the right account by tender: cash and mobile money settle to Cash, everything else to Bank. Refunds reverse into whichever one the original payment used.
Rent, utilities, subscriptions, bank charges. Posts the expense against Payables or straight to settlement depending on whether you pay now or hold it, and posts a second matching journal when the payable is later cleared.
Check-ins, check-outs and reason-coded adjustments move value between inventory and the account their reason implies, so a write-off and a receipt are different postings rather than the same one with a different note.
Posting an approved run recognises the cost and then settles it, in two pairs, referenced to the run and its period so the ledger line and the payslip batch point at each other.
Every outbound supplier settlement — bank transfer, mobile money, cheque — reduces payables and the settlement account together, from the same register that reconciles the payment itself.
Payments to people working on a project post to the same payroll expense account as the payroll engine, so project labour cost and payroll cost never disagree about what was spent.
Field adjustments, mobile POS and mobile invoice payments call the identical posting service as the browser. There is no second, looser accounting path for mobile work — which is the usual place a parallel ledger appears.
The journal is the flat chronological record: one row per leg, each carrying its account, its amount, the document that caused it, and the running balance of that account immediately after it. Page sizes run from 25 to 200 rows.
| Date | Account | Source | Amount | Running balance | |
|---|---|---|---|---|---|
| 24 Aug 14:06 | Taxes Payable | Output tax on INV-2098 | CR | 2,206.90 | 318,442.15 CR |
| 24 Aug 14:06 | Sales Revenue | Revenue for invoice INV-2098 | CR | 13,793.10 | 7,904,118.40 CR |
| 24 Aug 14:06 | Accounts Receivable | Revenue for invoice INV-2098 | DR | 16,000.00 | 1,244,905.60 DR |
| 24 Aug 11:52 | Bank | Payroll run 2026-08 (settled) | CR | 2,884,300.00 | 6,118,772.05 DR |
| 24 Aug 09:14 | Inventory Assets | COGS for POS sale POS-4471 | CR | 11,265.00 | 3,470,881.25 DR |
The large-entries filter deserves a sentence of its own, because it is the one filter here you could not have configured yourself. It does not compare postings to a number you typed. It computes the average entry amount across your own ledger and then shows you everything more than half again above it. A business posting thousands of small retail lines and a business posting a handful of large equipment purchases get a different threshold from the same control, and neither had to guess what "large" means in their books.
The ledger view walks the accounts that have actually been posted to — not every account you own, only the live ones — and shows each with its full entry history and a closing balance expressed in the sense that account naturally carries.
Normal balance is the idea that makes this readable. An asset or an expense account grows when you debit it; a liability, equity or income account grows when you credit it. AWRA knows which is which from the account's own type, and accumulates each account in its own direction — so Inventory Assets rising is a positive number, and Sales Revenue rising is also a positive number, even though one grew on a debit and the other on a credit.
The payoff is what happens when an account goes the wrong way. A cash account that has been overdrawn does not display as negative cash. The label flips instead: the number stays positive and the tag beside it changes from DR to CR, which is how an accountant would read it out loud and exactly what the trial balance needs. A negative number in a balance column is a presentation bug that hides a real condition. A flipped side is the real condition, stated.
Only accounts carrying at least one posting appear, so the ledger is never padded with empty rows from the chart of accounts.
Every leg ever written, each one still attached to the operational document that caused it.
Because the posting happens inside the operation, "how current are the books" and "how current is the business" are the same question.
A trial balance in most systems is a test — you run it to find out whether something has gone wrong. Here it is closer to a statement of the obvious, and that is the point.
| Account | Type | Debit | Credit |
|---|---|---|---|
| Accounts Receivable | Asset | 1,244,905.60 | — |
| Inventory Assets | Asset | 3,470,881.25 | — |
| Bank | Asset | 6,118,772.05 | — |
| Accounts Payable | Liability | — | 918,340.00 |
| Taxes Payable | Liability | — | 318,442.15 |
| Sales Revenue | Income | — | 7,904,118.40 |
| Cost of Sales | Expense | 4,182,900.10 | — |
| Payroll Expenses | Expense | 2,884,300.00 | — |
Being allowed into accounting is not the same as being allowed to read the general ledger, and neither is the same as being allowed to change the chart of accounts. Each of those is its own grant, and they stack.
That granularity is what lets you give a branch manager the aging report without handing them the whole ledger, or give a bookkeeper the journal without giving them the power to rename a system account the statements depend on.
view_accounting The floor. Without it none of the accounting screens exist for that role at all.
view_journal_entries Required on top of the floor for every ledger-derived screen — the statements included.
view_general_ledger The per-account drill-down specifically, so entry-level detail can be granted separately from summary reporting.
view_reports Gates the statements above the ledger: trial balance, income statement, balance sheet, cash flow, receivables and payables.
manage_accounts The chart of accounts itself. System accounts the reports are keyed to stay locked even here.
Every journal posting raises an event inside the platform, which means your workflow rules can watch the ledger the same way they watch a purchase order or a ticket. Post a journal above a threshold and notify the finance lead. Post to a particular account and open a review task. Post anything at all on a weekend and put it in a queue somebody checks on Monday.
This is a small thing that turns out to matter, because the alternative is a person remembering to look. A control that depends on somebody opening a report is not a control — it is a hope with a screen attached. Wiring the rule to the posting itself is how the check happens on the entry nobody was expecting.
Finance software is the worst possible place for a vague answer, so here is the shape of it precisely, including the work we would take on if you need it.
What AWRA OpsHub does today
More we can add to your workspace
Where we point you to a specialist
Everything in the middle column is scope rather than a ceiling — several of them are a few days of work on foundations that already exist. Tell us which you need and we will come back with a written spec, a timeline and a price to add it to your workspace.
One coupling worth knowing before you plan around it: revenue on an ad-hoc stock issue is recognised only where the movement's reason is flagged as revenue-generating, and that flag is matched on the reason's name. Rename a revenue reason and the postings that follow it need the flag set again on the new name.
Not on a reconstruction of it, assembled weeks later from bank lines and memory. Every posting in AWRA OpsHub is written by the operation that caused it, both legs at once, the moment it happens.