Amending a Xero Chart of Accounts: Add, Edit, Archive, Delete

The chart of accounts is the spine of the ledger. Every code you add, rename or retire changes what the reports can tell you, and some changes quietly restate months you have already closed. Here is the sequence we work through before touching the code list in Xero, and the judgement calls along the way.

Start with the reports, not the code list

Open the profit and loss and the balance sheet before you open the settings screen. Ask which line someone acts on, and whether that line is currently a muddle. If a report answers its question already, the chart does not need a new code. In Xero the chart of accounts sits under the Accounting menu, but the decision belongs to the reports, not to the settings.

When does a new code earn its place?

A code justifies itself when two different things share one line and you analyse them differently, or when volume makes a single account unreadable. Postage and courier is the classic case. While courier spend is trivial, one code is right. The month you start arguing about courier contracts, split it. A new code nobody reads is clutter, and clutter slows the close.

The account type does the real work

In Xero the account type decides where each code feeds: revenue, direct costs, expenses, assets, liabilities, equity or bank. Get the type wrong and the ledger still balances while the statements mislead. A loan repayment sitting in an expense account is balanced and wrong. Fix the type before anything posts to the new code. Changing it later restates history, which is its own problem below.

Add the code, then prove it

Decide the number, the name and the default tax rate together, so the code block stays tidy. Where your region applies tax on the account, the rate you set simply pre-fills new entries. Post one small test transaction, run the statement, and check the amount lands on the line you intended. Then remove the test entry. Ten minutes of proof here saves a cleanup at month end. Names matter more than you expect, because people picking from a list read the name, not the number.

Which edits change history you have already filed?

A rename is cosmetic: the numbers stand, and old transactions simply display the new words. A changed type is not cosmetic. Xero reports by account, so the whole history of that code moves to its new statement line. Anyone holding a filed set now has a mismatch. We treat a type change as a restatement. It needs the accountant's agreement, a note in the file, and ideally a date at the start of a reporting year.

The default tax rate behaves more kindly. It pre-fills future entries and leaves posted ones carrying the rate they were posted with. Re-coding past transactions is a separate question, and if the period has since locked you will need the right user role to touch it.

Deleting a code that has been used

Xero will only delete an account that nothing has touched: no transactions, and nothing that references it, such as bank rules or recurring templates. A code with history is archived instead. Archiving pulls the account from the pick lists while leaving its history on the statements.

That is exactly what you want. A deleted account would tear a hole in old months; archiving keeps them whole. System accounts Xero depends on, such as retained earnings, can be neither deleted nor given a new type.

Bank accounts sit in the chart too

Bank, credit card and payment-platform accounts are part of the Xero chart, but they anchor feeds, statement lines and reconciliations. We treat them with more caution than a plain expense code. A rename is safe. Creating a replacement and walking away from the old one strands the reconciliation history. If a bank account must truly be replaced, plan the switch at a statement boundary and keep the old account on the record.

A worked example: splitting one account into two

Suppose one code, Office expenses, has collected a year of stationery, software subscriptions and coffee. Software is now the biggest cost in it and nobody can size it. At the start of a quarter we add a new code, Subscriptions and software, and re-code the recurring card charges from that date. Old history stays in the original code. A one-line note on the report, office expenses split from April, tells any reader why the trend moved.

Keep a change log

Chart changes are working-paper material. One line per change: date, code, what changed, why, and who agreed. The log answers comparative questions later. It protects you when someone asks why last year's export does not match this year's. It also stops two people adding near-duplicate codes for the same thing in the same month.

Where does this stop being bookkeeping?

Adding, renaming and archiving codes in the live file is bookkeeping, and the steps above cover it. A full renumber, a conversion from another system, or a repair after file damage is different. Opening balances, history and mappings all have to travel together, and one wrong move strands them. That is specialist work. If that is where you find yourself, hand the file to people who do migrations for a living rather than improvising in a settings screen.