AWRA OpsHub Search
Chart of accounts

Call it whatever your business calls it. The wiring holds.

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

The idea that holds it together

A name is for people. A key is for the software.

Here 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.

The resolver

A posting can never fail for want of an account.

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.

1 The posting asks by key

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.

2 Your account is returned

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.

Or it is created, there and then

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.

3 Both legs are written

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.

Two natures

Every account grows in one direction.

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.

Debit-natured  ·  11 of the defaults Grows on a debit — what you hold and what you spend
  • cash
  • bank
  • accounts_receivable
  • inventory_assets
  • purchases
  • expenses
  • operating_expenses
  • payroll_expenses
  • fixed_assets
  • depreciation
  • work_in_progress

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.

Credit-natured  ·  5 of the defaults Grows on a credit — what you owe and what you earn
  • accounts_payable
  • payroll_payable
  • taxes_payable
  • sales_revenue
  • inventory_received_clearing

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.

System accounts

Some accounts you are not allowed to break.

Locked even for roles that manage the chart

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.

Three focused views

The accounts you look at most, on their own pages.

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.

Receivables & payables

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.

accounts_receivablecash_customeraccounts_payablesupplier_payable
Tax accounts

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.

vat_payablewithholding_taxincome_tax_payabletaxes_payable
Fixed asset accounts

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.

fixed_assetsoffice_equipmentfurniture_and_fixturesvehiclesland_and_buildings
Straight answers

What the chart does today — and what we can add to yours.

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.

The straight answer

What AWRA OpsHub does today

  • Every account carries a stable system key as well as a name, so statements and postings are wired to the key and renaming an account never breaks a report
  • Sixteen accounts configured on day one — cash, bank, receivables, payables, inventory, purchases, sales revenue, expenses, taxes payable, receiving clearing, work in progress, operating expenses, fixed assets, depreciation, payroll expenses and payroll payable
  • A self-healing resolver: a posting that needs a missing account creates it from the configured default and continues, so accounting is never the reason an operation is refused
  • A new account with a grouped key appears on the right statement line immediately — no mapping screen, no report configuration
  • One search box reading name, system key and nature together, rather than making you choose a column
  • Accounts grouped on screen by their debit or credit nature, which is the property that changes how the ledger reads
  • System accounts locked against deletion even for roles permitted to manage the chart, while staying freely renameable
  • Your own accounts archived rather than destroyed, recording who removed them and when
  • A System Defaults sync that re-creates any missing account, role, permission, reason, category or department, safe to run repeatedly
  • Three focused views — receivables and payables, tax accounts, and capitalised asset classes — each narrowed to its own keys
  • The whole chart available on the API for the mobile app and your integrations

More we can add to your workspace

  • Account numbering — a numbered code per account, sortable and reportable, in the scheme your auditor uses
  • A parent-child account hierarchy with subtotals rolling up through the tree, so a chart of two hundred accounts reads as a structure rather than a list
  • A per-account currency, with FX revaluation for balances held in a currency other than your base
  • Importing and exporting a chart of accounts as a file, for migrating from an existing system in one step
  • A custom statement mapper, so a new account group can be defined and placed on a statement line without touching configuration
  • Departmental or cost-centre segments on the account code, so the same expense can be read per branch
  • An account-level budget attached to the account itself, with variance shown beside the balance
  • Archiving an account with a guard that checks for postings first and offers to reassign them
  • A visual chart-of-accounts map showing which statement line each account feeds
  • Multi-book support, for a workspace that needs a statutory and a management chart side by side

Where we point you to a specialist

  • The structure of your chart of accounts is your accountant's design. We will build the accounts, groups and numbering scheme they specify; we will not impose a template and call it best practice.
  • Which account a novel transaction belongs in is a judgement for the person accountable for the accounts. Give us the rule and we will build the posting that follows it every time.
  • We will not map your chart to a statutory reporting taxonomy on our own authority. Tell us the mapping your filing requires and we will build it exactly.
  • Deleting an account that carries postings is not something we will make easy, on any permission. That history is the audit trail, and a system that lets it vanish on a click cannot be audited.

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.

Questions, answered

Chart of accounts FAQ.

Can I rename accounts to match our own language?
Yes, freely, including system accounts. Reports and postings are wired to each account's system key rather than its name, so nothing follows the label. This is the single most useful consequence of the whole design.
If I create a new account, will it show up on my statements?
If you give it a grouped system key, immediately — on the line that key belongs to. If you leave the key empty, it works as a perfectly good account that simply stays out of the grouped statements, which is often what you want for something you are tracking on the side.
What if somebody deletes an account we need?
The accounts the statements are keyed to are flagged as system accounts and cannot be deleted, whatever permission the person holds. And if a workspace's setup has drifted for any other reason, System Defaults sync re-creates anything missing and leaves everything present untouched.
Do accounts have numbers like 1000, 1100, 2000?
Not today — accounts are identified by name and system key, and the chart is flat rather than a tree. Numbering and a parent-child hierarchy with rolled-up subtotals is the most-requested addition here, and because the wiring runs on keys it can be added without disturbing a single existing report.
What is the receiving clearing account for?
It holds the value of goods received but not yet invoiced, so a delivery that arrives before its paperwork does not distort your payables balance. It clears when the supplier invoice is matched.
Can I hold an account in US dollars while my base currency is something else?
Not yet. The ledger runs in a single currency today. Per-account currency with a period-end revaluation and an FX movement line is work we can add.
Can we import our existing chart of accounts?
Not as a file upload today. Accounts can be created through the screen or over the API, so a scripted migration is straightforward; a first-class import with a mapping preview is on the list above.
Ready when you are

Start with sixteen accounts that already work.

Then rename them, add to them, and shape them to your business — without a single report quietly stopping working while you do it.