When a new account breaks your bookkeeping automation

Someone adds an account to the chart of accounts. Splits Meals into Meals and Client Entertainment, say, because the old category had stopped being useful.

It is a five-second edit, it is correct bookkeeping, and it does not announce itself anywhere. Weeks later, expenses coded to the old category refuse to export, and somebody starts hunting for a broken connection that is not broken.

This article is about that specific failure: what the software vendors document about it, how little either platform will tell you afterwards about who did it, and the one setting that turns it from silent into obvious.

The connection is fine. That is the problem

The instinct when an export fails is to check the integration. Reconnect it, re-authorise it, watch it go green.

Expensify's own error documentation heads that off in one line. Its ONL531 error - raised when a mapped account no longer exists or is inactive - says plainly: "This is a QuickBooks Online mapping issue, not a connection issue." Its ONL056 error repeats the point.

That distinction is the whole subject. Two systems are talking normally. The list they agree on has changed underneath them, and nothing in the handshake between them notices.

What actually happens when someone adds an account

Three vendor-documented mechanisms. Worth being precise about what each one does, because adding an account on its own rarely breaks anything - every documented export error fires on an account that was deleted, deactivated or renamed. The catch is that splitting a category is almost never only an addition: the old account gets deactivated so nobody codes to it again, and that is the half that breaks things.

A refresh window you cannot shorten. Dext syncs the chart of accounts on its own schedule, roughly every 48 hours, and a manual re-sync is available only to administrators. So the client who creates the account is usually not the person who can make the system see it, and for up to two days nothing is wrong except that one system knows something the other does not.

A setting that can hide new accounts entirely. Expensify imports the chart of accounts as categories, an import that "is enabled by default and cannot be disabled". Then, in its advanced settings, sits this option: "Newly Imported Categories Should Be: Choose whether newly created accounts in QuickBooks Online appear enabled or disabled in Expensify. Disabled categories will not be visible to employees when coding expenses."

Read that twice. A workspace can be configured so that every account the client creates arrives switched off and invisible to the people coding expenses. Nothing errors, nothing is announced, and the account exists in one system while being functionally absent from the other. Check which way yours is set - the documentation describes the choice, not a default you can assume.

A checkbox in Xero. A brand-new, perfectly valid expense account can be invisible to a connected app because of one field. Xero's API specification documents ShowInExpenseClaims as describing "whether account code is available for use with expense claims", and Xero's own sample account has it set to false. Expensify's XERO73 error states the consequence: only accounts eligible for expense claims get imported. No deletion, no rename, no error - just a box left unticked on creation.

The symptom has a vendor's own name on it

Expensify publishes a numbered catalogue of export errors, and a cluster of them describes exactly this root cause surfacing weeks late.

ONL056 refuses the export because "expenses must be categorized to a QuickBooks Online account", and lists among its causes that the selected category "is no longer synced from QuickBooks Online" or "does not exist in the current QuickBooks Online Chart of Accounts". ONL531 fires when a mapped account has been deleted. Alongside them sit "Account not found" and "Invalid account type", and a Xero variant that spells out the checkbox: confirm the category is active, of Expense type, and has Show in Expense Claims ticked.

What that means in practice is that the expenses coded to the affected category stop moving while everything else in the batch goes through. Nobody set out to export half a month; it just turns out that the half nobody could code correctly is the half that stays behind.

Who finds out, and when

The alert goes to whoever the software thinks is responsible, and that is rarely the person who made the change.

In Expensify's documented behaviour, the preferred exporter gets an email with the error details, the error appears in the report's comments, and automatic exports keep failing until it is resolved. That is a reasonable design. It also means the notification lands with the bookkeeper or the finance lead, days after a client edit that nobody logged, in a mailbox that already receives a lot of automated post.

This is the same shape as every other automation that fails silently: the run completes, the status is green somewhere, and the thing you actually wanted did not happen. What makes this variant harder is that the cause is administrative. Nobody broke anything. Somebody did ordinary bookkeeping in the ordinary place.

Why you cannot simply take the rights away

The obvious fix is to stop clients editing the chart of accounts. It is also the first thing most bookkeepers suggest, and it collides with what the platforms actually allow.

In Xero it is not possible. Xero states that you need the standard or administrator role to view the chart of accounts, and its role comparison shows both roles with full access to import, export and edit it. Standard is the lowest role that reaches the chart of accounts, and reaching it means being able to change it. Xero acknowledges the general limit itself: you cannot fully customise which areas a user gets. Lock dates do not help either - they stop backdated transactions, and say nothing about the account list.

In QuickBooks Online it depends on what you pay. Custom roles, where "Chart of accounts" is a permission you can set to view, create or edit, exist only on Advanced and Intuit Enterprise Suite. On the smaller plans the roles that can do general bookkeeping - Standard all access, In house accountant - both include "Add, edit, and delete accounts". The roles that cannot touch accounts are narrow ones built for receivables, payables and limited customer-vendor work.

A note if you are checking this yourself: both vendors renamed their role catalogues, and most advice online still uses the old names. In QuickBooks the familiar Standard user and Reports only are gone from the current page; in Xero, Adviser and Read Only now read Administrator and Viewer.

The access question here is the same one worth asking of every integration you own - whose account does this actually run on, and what happens when that person's permissions change.

Looking up who did it: one platform can, one cannot

This is the part that surprises bookkeepers, and the two platforms differ enough that it is worth knowing which one you are on before promising a client an answer.

Xero does not record it. Its history and notes feature lists what it does not cover, and the chart of accounts is on that list, alongside reports and organisation settings. The org-level history report - the one Xero itself says people call an audit trail - covers invoices, bills, contacts, inventory items, fixed assets and financial settings. Accounts are not in scope. So when an account appears and a mapping breaks, Xero will not tell you who added it or when. Its Assurance dashboard, which does flag edited contact bank details, does not watch the account list either.

QuickBooks records more, and promises less than you would want. Its audit log cannot be turned off, keeps two years of events, and covers, in Intuit's words, "all account activities". But no Intuit page enumerates chart-of-accounts events among the things it captures, so treat that as broad coverage rather than a documented guarantee, and check your own file before relying on it. One genuinely useful detail: changes made by connected apps appear under System Administration, which is how you tell machine edits from human ones.

There is also a wrinkle in cleanup. Merging duplicate accounts in QuickBooks is done by renaming one to match the other, and Intuit warns that the account being merged loses its reconciliation history, though the transactions themselves stay put and stay reconciled. Save the reconciliation reports before you tidy up.

The setting that makes it loud

Most advice about catch-all categories says to eliminate them. Uncategorized expenses are a sign of sloppy bookkeeping, so the tidy answer is to have nowhere for an unrecognised item to land.

The opposite is worth considering here, and one vendor already ships it. Bill.com documents an Unallocated Expenses Account: if an expense account is not specified, this account "will serve as a catch-all in your accounting software, where you know to look for bills that need to be coded", suggesting names like Ask my Accountant or Uncategorized Expense.

Notice what that design does. Bill.com fails loudly into a visible account. Expensify's disabled-category default fails silently into nothing. The same underlying event - an account the app does not recognise - produces a balance you can see in one system and an absence you cannot in the other.

So make it deliberate. Point unmapped items at an account named for the job - Uncategorized, needs mapping - and treat its expected balance as zero. Then the detection is a single number checked before close: if that account is not empty, someone changed the chart of accounts during the period. Not a report to read, a balance to glance at.

Two honest caveats. Not every app lets you choose the destination for unmapped items - Expensify's failure mode is the category being disabled rather than redirected - so check what yours does before designing around it. And a catch-all only works while its expected balance is zero; the day it habitually holds something, it has become the mess it was meant to detect.

Whose job this is, on paper

Here is a gap worth knowing about: the professional guidance does not cover it.

The independence rules written for audit engagements treat coding transactions as the client's own act, and engagement letter templates from professional bodies handle scope, fees, liability and the supply of information. What none of them appear to contain is a clause about the chart of accounts itself: who may change it, and what happens to the connected systems when someone does.

Which means it is on you to write. One sentence in the engagement letter is enough: the client agrees not to add, rename or deactivate accounts in the chart of accounts without notifying you first, because connected systems hold their own copy of that list. Say why in the sentence. A rule with its reason attached gets followed; a rule that reads like bureaucracy gets forgotten by the person who just wanted a category for entertaining clients.

The clause and the catch-all are not alternatives. The clause covers the clients who remember. The catch-all covers everyone else, which over a year is most people.

Put the check where the failure is

Everything above collapses into a short routine:

1. Find out what your app does with new accounts. Are newly imported categories enabled or disabled by default? Is there a destination for unmapped items? Test it - create an account, wait for the sync, look. Do not read the setting and assume.
2. Set the catch-all where the app supports one, name it so nobody mistakes it for a real category, and write down that its expected balance is zero.
3. Check that one balance before you reconcile, not after. In Xero, remember that the account list has no history to fall back on, so the check is the only detection you have.
4. Re-sync the chart of accounts at the start of month end. If your app refreshes on a two-day cycle, a manual sync before you begin costs seconds and closes the window that matters.
5. Add the sentence to your engagement letter, and tell the client the reason out loud once.
6. If you are choosing a plan anyway, know that locking the chart of accounts is a paid feature in QuickBooks and does not exist in Xero. That is a real input into the decision, not a footnote.

None of this is automation. It is the small amount of design that keeps automation honest - the difference between a system that tells you it broke and one that waits for you to notice.

If you want the same look taken across your whole admin, that is what the process audit is for: $299, three business days, and a written account of where the quiet failures are.

Sources

Expensify, on how the chart of accounts arrives and what happens when it moves: configuring the QuickBooks Online connection, the ONL531 mapping error, the ONL442 partial export, and where export errors are sent.

From Xero: the Account schema in its API specification documents the expense-claims flag; viewing the chart of accounts and role access to settings cover who may change it; what is recorded appears in history and notes, the history and notes report and the assurance dashboard.

From Intuit: user roles and access rights, custom roles on Advanced, the audit log, and merging duplicate accounts.

Bill.com documents its catch-all account and conflict rules in sync preferences.

Also used here: Dext on how often it refreshes the chart of accounts and who may trigger a sync; Expensify's XERO73 and XERO93 errors; and Xero on lock dates and user roles.