Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
Every account in AWRA OpsHub carries two identities: the name you chose, and a stable system key underneath it. Reports and postings are wired to the key. So you can rename "Operating Expenses" to "Overheads" on a Tuesday afternoon and nothing anywhere stops working.
16 accounts configured on day one · Search name, key and type together · Locked system accounts · Archived, never destroyed
payroll_expensesSYSTEMpurchasesSYSTEM—accounts_payableSYSTEMpayroll_payableSYSTEMtaxes_payableSYSTEMHere is a failure that happens in a great many accounting systems, and it is worth naming because it explains this whole design. A finance lead renames an account — perfectly reasonably, because "Sundry Expenses" meant something in 2018 and nothing now. Somewhere a report was matching on that name. The report keeps running. It just quietly stops including that account, and the number it produces is now wrong in a way nothing announces.
AWRA avoids that by never asking the software to read the label. Every account carries a system key — a short, stable identifier like accounts_receivable — and it is the key that the income statement's revenue group, the balance sheet's asset group, the cash flow classification and every posting routine are wired to. The name is yours to change at will. Nothing follows it.
It also works the other way round, which is the more useful half. Create an account, give it a grouped key, and it appears on the right statement line immediately — no report configuration, no mapping screen, no support ticket. Create one without a key and it is a perfectly good account that simply stays out of the grouped statements, which is often exactly what you want for something you are tracking privately.
When a POS sale needs somewhere to put revenue, it does not look for an account called "Sales Revenue". It asks for the key — and there is a fallback behind that request, which is the part worth understanding.
The routine says "give me the account for sales_revenue" rather than naming it. Nothing in the posting layer knows or cares what you call it.
If an account with that key exists for your workspace, that is the one used — whatever its name, whatever you have renamed it to since.
If no such account exists, the configured default is used to create it — with its name, description, nature and system flag — and the posting continues to its matching leg.
Because the account was always going to be there, a half-written entry is not a state the ledger can reach through a missing account.
That third box is the whole point of the design. The obvious way to build this is to validate up front — check the account exists, refuse the operation if it does not, show an error. It sounds safer and it is much worse in practice, because the operation being refused is a cashier taking money on a Saturday, and what happens next is that the sale goes through a different route with no accounting behind it at all. Self-healing account resolution means the accounting never becomes the reason an operation cannot happen.
There is also a repair path for the opposite case, where something has been removed or a workspace predates an account being added. System Defaults sync re-creates any missing account, role, permission, reason, category or department in one action, leaving everything already present untouched. It is the button for "our setup has drifted", and it is safe to press twice.
An account's nature decides which way its balance accumulates, and it is the one property that changes how the ledger reads. Sixteen accounts ship configured: eleven debit-natured, five credit-natured.
Receive stock and inventory rises on a debit. Pay a bill and the expense rises on a debit. When one of these swings the other way — an overdrawn bank account — the ledger flips the side label rather than showing you a negative number.
Bill a customer and revenue rises on a credit. Accrue tax on a fulfilled invoice and the liability rises on a credit. The receiving clearing account is the interesting one here: it holds the value of goods received but not yet invoiced, so a delivery that arrives before its paperwork does not distort payables.
An account the statements are keyed to is flagged as a system account, and that flag survives the permission that lets somebody manage the chart of accounts. Being trusted to add accounts is not the same as being trusted to delete the one the balance sheet is built on — and the difference between those two only becomes visible at the moment somebody has already done it.
You can still rename a system account freely, because the name was never load-bearing. What you cannot do is remove it out from under the reports.
Accounts you create yourself are yours to remove — and even then they are archived rather than destroyed, with the person who removed them and the moment they did it recorded on the row. An account with postings behind it is part of your audit history, and a system that lets that history vanish on a click is a system that cannot be audited.
Each of these is the same account data, narrowed to a set of keys, so a person who only needs one of them does not have to read the whole chart.
Both sides of what is owed, side by side with their totals — receivable accounts on one side, payable accounts on the other, each expandable to the postings behind it.
This is the account-level view. For the per-customer and per-supplier breakdown with buckets and reminders, the aging report is the screen you want.
Every tax liability account with its balance and its entries, presented as a positive figure throughout — because what you want from this screen is "how much tax is sitting here", not a sign convention.
Output tax arrives here automatically, split off each fulfilled customer invoice at the moment of fulfilment rather than calculated at filing time.
The five capitalised classes with their balances, feeding the fixed assets line on the balance sheet — and separate from the operational asset register, deliberately.
The register page explains which figure is which, and is straight about what the value trend on it does and does not mean.
The account structure is the foundation everything else here sits on, so here is exactly what it is, and what we would build onto it.
What AWRA OpsHub does today
More we can add to your workspace
Where we point you to a specialist
Account numbering and a parent-child hierarchy are the two most-asked items here, and they are additive — the key-based wiring underneath means adding a code and a parent does not disturb a single existing report. Tell us your scheme and we will come back with a written spec, a timeline and a price.
Then rename them, add to them, and shape them to your business — without a single report quietly stopping working while you do it.