Client Onboarding Without Re-Typing

The data was already correct. It became wrong when a human retyped it.

A prospective client says yes. Somebody opens the email that started it all, opens Xero Practice Manager in another tab, and types across the name, the contact details, the entity type and the ABN. It takes four minutes. It happens once per new client, and nobody has ever put it on a list of problems.

It is worth looking at more closely, because the time is the least interesting thing about it.

Re-keying is a defect source

Every one of those details was already correct. The prospect typed their own name into your form and got it right, because it is their name. The ABN they supplied was theirs.

Then a person read it off one screen and typed it into another, and at that moment the data acquired a defect rate it did not previously have. Transcription error rates for manual keying are commonly cited in the low single-digit percents per field, and while the exact figure depends heavily on the task, the direction is not in dispute: copying data by hand makes it worse.

That is the part that costs real money, and it costs it later. A transposed ABN digit does not announce itself. It sits in the record until a lodgement fails, or correspondence goes to the wrong entity, or a reconciliation will not balance, and by then the person tracing it has no idea it originated in a four-minute typing job three months earlier. You do not pay four minutes. You pay four minutes plus an occasional afternoon.

Why the step survives

Because it looks like nothing. Nobody schedules "type in the new client". It happens in the gaps, it is never on a timesheet, and it is invisible in every report you have. Work that nobody measures cannot appear in a prioritisation exercise, so it never gets fixed.

There is also a legitimate fear underneath it, and it deserves a straight answer. The step feels like a control. Somebody looks at the client before they are created in the system, and that looking is genuinely valuable. The mistake is assuming the looking and the typing have to be the same activity. They do not, and conflating them is why this survives in practices that have automated much harder things.

The shape of the fix

Keep the judgement. Remove the transcription.

The approval stays with a person. Somebody reviews the lead and decides whether to take them on. That is a business decision with real consequences and it is not a candidate for automation.

The creation happens on approval. The instant a human clicks approve, the client record is created in Xero Practice Manager from the data the client themselves supplied. Nothing is retyped, so nothing can be mistyped.

The ABN is validated before creation, not after. The lookup runs against the ABR, and the result gates the record. If the ABN does not resolve, or resolves to a different name, no record is created and the lead is flagged.

The lead's status updates itself. It flips to active client automatically. Two systems agreeing without anyone reconciling them is most of the value here, and it is the part people forget to ask for.

Fail closed, always

The single most important design decision in this whole flow is what happens when something goes wrong.

The tempting behaviour is to create the record anyway and flag the problem for later. It keeps things moving, and it is almost always wrong. A client record with a bad ABN is worse than no client record, because no record is obvious and everybody notices immediately, whereas a bad record is invisible and gets built upon. By the time it surfaces, invoices reference it.

So the rule is: when a step cannot complete correctly, stop and raise it. Do not write partial data and carry on. A noisy failure that pauses costs somebody five minutes of attention today. A quiet failure that proceeds costs an afternoon of forensics later, and it costs it at the worst possible moment, because these things surface at lodgement deadlines.

This is also why "it works" is not the acceptance test. The acceptance test is that you deliberately feed it a bad ABN, a duplicate client and a missing entity type, and confirm it refuses all three loudly.

The edge cases are the actual project

The integration is not the hard part. Connecting to a practice-manager API and creating a record is a well-trodden path. What takes the time is agreeing what should happen when reality does not match the happy path, and every practice answers these differently:

An individual or sole trader with no ABN at all. This is normal, not an error, and the flow must branch rather than fail.
An ABN that resolves to a trading name that does not match what the client typed. Sometimes legitimate, sometimes a red flag, always a human decision.
A client who already exists, because they were a client four years ago.
A trust or partnership where the entity that signs is not the entity that trades.

We spent more time on that list than on the Xero connector. That is the normal ratio, and any quote that does not account for it is quoting the wrong project.

What it produced in practice

For OzLedger, this runs today. Approve a lead and their profile is created in Xero Practice Manager on its own, with the ABN checked and validated first, and the lead marked an active client. No details are re-typed from an inbox.

The measurable win is the time, and it is real but modest. The win that actually changed how they work is that the lead dashboard and Xero now say the same thing without anyone making them agree, and nobody has to remember to do a step that was never written down anywhere.

Key takeaways

Re-keying is a defect source, not just a time costTranscription introduces errors into records that were already correct, and those errors surface months later.
Validate at the boundary, onceCheck the ABN when the record is created, not when someone notices something is wrong at lodgement.
Keep the human approval, remove the typingThe judgement call is worth a person. The copying is not.

Frequently asked

Does this work with Xero Practice Manager specifically?

Yes, that is what we built it against. The pattern is not Xero-specific, but the implementation is: the practice-manager API is what creates the client record, and a different practice system would need its own connector.

What happens if the ABN lookup fails?

The record is not created and the lead is flagged for a human. Failing closed is deliberate. Creating a client record with an unvalidated ABN quietly produces a compliance problem that nobody discovers until lodgement.

Do we lose the ability to review a client before taking them on?

No, and you should not want to. The approval step stays with a person. What is removed is the typing that happens after the decision, not the decision itself.

What about clients without an ABN, like individuals?

They are a normal path, not an exception. The flow branches on entity type: individuals and sole traders without an ABN skip the lookup entirely rather than failing it, which is the mistake most first implementations make.

How long does this take to implement?

For a single practice with a working Xero connection and a defined approval step, two to four weeks. Most of that is agreeing the edge cases, not writing the integration.