Xero approval workflows and custom fields: what's missing and what it costs

No, to both — and they are the same problem wearing two hats. Xero’s bill approval is a single status change from Draft to Awaiting Payment, with no routing by amount, no sequential chain and no delegation. Contacts and invoices accept no custom fields at all. Both gaps exist because Xero models a company’s ledger, not a company’s policy, and a policy is exactly what a group of entities runs on.

This is the guide we promised at the end of the cost of running twenty companies on Xero. Those two gaps are where most of the manual work in a multi-entity finance team actually accumulates, so they are worth taking apart properly rather than listing.

What does Xero’s bill approval actually do?

It marks a bill as approved by someone who holds the right user role, and that is the whole of it. A user with the Standard or Adviser role can move a bill from Draft to Awaiting Payment. Xero records who did it and when, which is a real audit trail and should not be dismissed — but the decision it records is binary.

What it does not carry is the shape of an actual approval policy. There is no threshold, so a $200 stationery bill and a $200,000 subcontractor claim take the same single click from the same person. There is no sequence, so you cannot require a business unit leader and then a finance director. There is no delegation, so when the approver is on leave the work either stops or somebody shares a login. And there is no separation between “I confirm this was received” and “I authorise this payment” — two different people making two different judgements, collapsed into one status.

Xero does offer approval limits on purchase orders and expense claims, which confuses the picture. Those are genuinely useful and genuinely not the same thing: a purchase order approves a commitment before it is made, and most groups’ control problem sits on the bill that arrives afterwards, often without a matching PO.

Why can’t you add custom fields to a Xero contact?

Because the contact record has a fixed schema, and Xero has declined to make it extensible for well over a decade. The request has been open on Xero’s own product ideas forum since 2012. It remains one of the most-voted ideas there and is standard in comparable mid-market systems.

The practical consequence is that any attribute your business needs and Xero did not anticipate has nowhere to live. In the groups we see, that list is remarkably consistent: a supplier’s insurance certificate expiry, an ABN verification date, the entity code a shared supplier trades under, a contract reference, a preferred payment term that differs from the default, an internal risk rating, whether bank details have been verified since the last change.

None of that is exotic. It is the ordinary metadata of managing suppliers. Because it cannot be stored against the supplier, it goes into a spreadsheet beside Xero — and a spreadsheet beside Xero is not a harmless inconvenience. It is a second source of truth that nobody owns, that no integration reads, and that is wrong more often than anyone admits because updating it is a separate act of discipline from updating Xero.

What do people actually use instead?

Four workarounds, in rough order of how many groups reach for them. Each solves part of the problem and creates a different one.

Contact groups and tracking categories. Xero’s own fields, pressed into service as pseudo-custom-fields. Contact groups can encode one dimension — a risk tier, say. Tracking categories can encode two, and only two are available with around a hundred options each. It is free and it is inside Xero, which matters. But you run out of dimensions almost immediately, and the usual next step is encoding two things into one category name, which nothing downstream can parse.

A spreadsheet. Honest about what it is, and genuinely the right answer at three or four suppliers. The failure is not the spreadsheet itself but the lack of a trigger: nothing tells you an insurance certificate expired last Tuesday, because a spreadsheet does not watch itself.

Email as the approval chain. The most common by far, and the least visible. The policy lives in people’s heads, the evidence lives in inboxes, and the bill sits in Draft in Xero until someone remembers. It works until an auditor asks who approved a specific payment, or until the person holding the chain in their head leaves.

A layer above Xero. Approval routing, supplier metadata and the audit trail live in a system that reads from and writes to each Xero organisation. This is the only option that survives an entity count above roughly five, and the honest cost is another system to administer and another subscription. Whether that subscription is priced per organisation or per group matters more as the entity count rises; we work through both models in APBuddy vs ApprovalMax for multi-entity Xero.

Does an approval workflow tool fix the custom field gap too?

Usually, and that is the reason to treat the two gaps as one decision rather than two purchases. An approval layer has to store its own record of each bill and each supplier in order to route anything — which means it already holds a place where supplier attributes can live.

So the insurance expiry that had no home in Xero can sit on the supplier record in the layer above, and — this is the part that changes the work — it can become a condition. A supplier whose insurance lapsed can be blocked from approval rather than merely flagged in a spreadsheet nobody opened. A bill over a threshold can route to a second approver automatically. A new supplier can require bank verification before any payment is authorised.

That is the difference between storing metadata and using it. A custom field that only humans read is a spreadsheet with extra steps; a custom field that gates an approval is a control.

What should you check before buying anything?

Whether your problem is actually approval routing, because a good share of the time it is not. Three questions settle it quickly.

First, how many bills a month genuinely need more than one person’s judgement? If the answer is under ten, a documented policy and Xero’s existing audit trail may be enough, and the honest recommendation is to change nothing.

Second, how many entities? One or two organisations make most of this survivable, because switching is cheap and one person holds the whole picture. The arithmetic changes sharply somewhere around five, when no single person can hold it any more.

Third, what would an auditor need to see, and how long would it take you to produce it? If the answer involves searching an inbox, the gap is evidence rather than routing — and evidence is the cheaper problem to fix.

If those three point at a real need, the thing to test in a trial is not the feature list. It is whether the tool writes back to Xero cleanly, because an approval layer that requires re-keying into Xero afterwards has moved the manual work rather than removed it.

Is Xero likely to add these?

Not on any timeline worth planning around. The custom fields request has been open since 2012 and multi-step bill approval has been requested nearly as long. Xero has invested in other directions — bank feeds, reporting, the app ecosystem — and the app ecosystem is the answer it has effectively given: these are gaps the marketplace fills.

That is a defensible product position, and it is worth reading it as a statement of intent rather than a backlog. Xero is built to be one company’s ledger, and it is very good at that. The moment your policy is more complicated than your ledger, the policy needs somewhere else to live.

APBuddy is one of the systems that provides that layer, built specifically for groups running several Xero entities — approval routing by amount and sequence, supplier records that hold the fields Xero will not, and a write-back that posts the approved bill into the right organisation. If that is the shape of your problem, tell us about your setup.