Automating back-office work at a mid-size company

The exception rate decides everything

Every back-office process has a clean path and a messy one. Invoices that match a purchase order and a receipt go through untouched; the rest go to a person. Orders that arrive in the standard format post themselves; the rest go to a person. The clean path is cheap already, because it is the part everyone has been optimising for a decade. Automation projects are almost always sold against the clean path and judged, eventually, on the messy one. If a process runs seventy-eight percent clean today, the honest question is not how to automate the seventy-eight. It is what happens to the twenty-two, because that is where the cost, the risk and the calendar all live.

There is a failure mode with a particular shape here and it is worth naming before anything else. A company automates the clean path, sees a real reduction in effort, reduces the team accordingly, and then discovers that the messy path has not changed at all in volume while the people who used to absorb it in the gaps of their day are gone. Throughput on exceptions falls, the ageing report gets worse, and the automation gets blamed for a problem it did not create but did expose. The fix is not to automate less. It is to design the exception path first and the clean path second.

Four kinds of back-office work, and only two automate well

Sorting the work by kind, rather than by department, gets a plan out of a wish list quickly.

Kind of work	Examples	What to do with it
Deterministic rules on structured data	Three-way match, bank reconciliation, dunning, tax code assignment, recurring journal entries	Automate fully. No model needed. The reason it is still manual is usually a missing integration, not a hard problem
Reading documents that vary	Supplier invoices, remittance advice, order forms, certificates, onboarding paperwork	Automate with review. Extraction plus a confidence threshold plus a screen where a person corrects the rest
Judgment against a written policy	Expense approvals, credit limits, exception approvals, coding an unusual spend	Assist, do not replace. Prepare the decision, show the policy and the evidence, let a person commit it
Judgment without a written policy	Negotiating a disputed charge, deciding whether to press a customer, handling a supplier relationship	Leave it alone. Give the person better information and stop there

The second row is where most current interest sits and where the most money is wasted, because the demo is easy and the production system is not. Reading a supplier invoice is trivial on the six examples in a sales meeting and hard across the four hundred layouts in your inbox, the ones that are photographs of paper, the credit notes that look like invoices, and the vendor who puts the total in a footer.

The third row is where the most durable value sits and it is undersold, because "prepare the decision" makes a poor headline. A screen that shows an approver the request, the relevant policy clause, the last three similar decisions and what is unusual about this one, then takes a single click, is a large improvement over an email chain and carries almost none of the risk of an automated approval.

The arithmetic to do before the vendor call

Four numbers per process. They take a fortnight to gather and they change the conversation completely, because every vendor claim becomes checkable.

Volume. Transactions per month, with the seasonal peak, not the average. Systems are sized and staffed for the peak and justified on the average, which is how a January backlog becomes a surprise.

Current straight-through rate. The share that completes today with no human touch at all. Measure it rather than asking; the answer people give is generally the share that completes without a problem, which is a different and much larger number.

Fully loaded cost per transaction. Team cost divided by volume, including the supervisor, the systems, and the people in other departments who get asked questions. Do not use a published industry benchmark. Yours is knowable in an afternoon and the benchmark is measuring companies unlike you.

The cost of being wrong, in both directions. A duplicate payment, a missed discount, a late filing, an unhappy customer, an audit finding. And on the other side, the cost of a false exception: a transaction held up for review that did not need it. Both numbers set the confidence threshold later, and without them the threshold gets set by whoever complains most.

Put them together and the case appears without any adjectives. Forty thousand transactions a year at a straight-through rate of seventy-eight percent leaves eight thousand eight hundred that need a person. If each takes nine minutes, that is about thirteen hundred hours, and at a loaded seventy dollars an hour, roughly ninety thousand dollars a year of effort sitting in the exception queue. That is the target. Raising straight-through from seventy-eight to eighty-eight percent removes four thousand exceptions and about forty thousand dollars of it, which is a real result and is not the number in the brochure.

Do not automate the process you have

Sit with an exception queue for two days and sort the exceptions by cause rather than by type. In most back offices a large share of them are not judgment calls at all. They are defects created upstream by somebody else: a purchase order never raised, a receipt never entered, a vendor record with an old remit-to address, a customer master with two entries for the same company, a contract term that lives in a PDF nobody parsed.

Those exceptions can be automated, in the sense that a system can be built to handle them. They can also be eliminated, by changing what happens upstream. Eliminating is cheaper, faster and permanent, and it is systematically under-chosen for a boring organisational reason: the cost is borne in the department that creates the defect and the benefit lands in the department that absorbs it. A project sponsored by finance will find it easier to buy software than to change how procurement raises an order.

That is a political problem with a technical tell. If your exception categories are dominated by missing or mismatched reference data, you have an upstream problem and automation will preserve it in amber, at a monthly cost, forever.

A useful sequence: sort exceptions by cause, name the top three causes, ask for each whether it is a data problem, a process problem or a genuine judgment call, and only then decide what to build. Two weeks of that work routinely removes a third of the scope of a project, which is the cheapest scope reduction available to anyone.

Controls are the constraint, and also the best argument for doing it

Back-office processes carry controls, and an automation project either respects them or creates an audit problem that arrives later and costs more than the project saved.

Segregation of duties still applies when one of the parties is software. If a system can both create a vendor and approve a payment to it, you have built the control weakness the segregation rule exists to prevent, and it will be found. Automated actors need identities, permissions and a documented scope exactly as people do.

The audit trail has to say who, what, when and on what basis. For an automated step that means recording the rule or model version, the inputs, the confidence, and the human who reviewed it if anyone did. "The system did it" is not an answer an auditor accepts, and reconstructing it after the fact is expensive.

Change management becomes a control. If a public company, the Sarbanes-Oxley section 404 assessment of internal control over financial reporting will reach any automated step in a financial process, and the general controls around access and change will be examined alongside it. Practically this means a release process, a record of who approved a change to a rule, and an environment where a threshold cannot be edited in production by one person on a Friday.

The compensating benefit is genuine and often undersold internally. A manual control is tested on a sample; an automated control that is properly evidenced runs on every transaction and produces its own population evidence. Framed that way, automation strengthens the control environment rather than threatening it, and that framing is what gets an internal audit function on your side rather than in the way.

What it costs

Scope	What it includes	Typical range	Calendar
Process assessment	Volumes, current straight-through rate, exception causes ranked, a written scope and acceptance test	$20K–$50K	3–5 weeks
Integration and rules	Removing a re-keying step, deterministic matching, the review queue and reporting	$60K–$160K	8–16 weeks
Document reading in production	Extraction, a labeled test set, confidence thresholds, correction screen, monitoring	$90K–$250K	3–7 months
Decision support for approvals	Policy surfacing, evidence assembly, one-click commit, full audit trail	$70K–$180K	8–16 weeks

Add a recurring cost of roughly fifteen to twenty-five percent of the build per year. For document work, budget separately for keeping the labeled test set current, because vendors change their layouts and a test set that reflects last year's mail is a test that passes while the system degrades.

The staffing conversation, honestly

Business cases for back-office automation are usually written in headcount because headcount is the line an executive committee understands. In practice that is the least reliable part of the case, and building the project on it is how a good system acquires a bad reputation.

What actually happens in most mid-size companies is smaller and slower than the model: a role that becomes vacant is not refilled, overtime falls, temporary staff at quarter-end are not brought in, and one or two people move to work that was being deferred. Each of those is real money. None of them arrives in the month the system goes live, and all of them are invisible on a headcount report because the number does not go down, it stops going up.

The benefits that show up reliably and quickly are cycle time and error rate. Invoices posted in two days instead of nine. A close that finishes on day five instead of day nine. Duplicate payments falling to near zero. Discounts captured rather than missed. Those are measurable within a quarter, they do not depend on anyone leaving, and they are the numbers to put in the case. If a project only works on the headcount line, be suspicious of it, and be more suspicious of a vendor who volunteers that line first.

One more thing worth saying out loud to the team doing the work, early and directly. Everyone in that department has already worked out what the project is. Vague reassurance is heard as confirmation of the worst reading, and the people who know where the exceptions come from are the people whose cooperation the project depends on. A specific commitment, even a limited one, buys more accurate information than a comfortable one.

How these projects fail

• The clean path automated and the exception queue left as it was, so throughput on the hard work falls
• No measured baseline, so the improvement is a matter of opinion six months later
• Upstream defects automated instead of eliminated, preserving them permanently at a monthly cost
• A confidence threshold set by whoever complained, rather than by the cost of an error in each direction
• An automated actor with no identity, quietly breaking segregation of duties
• A test set built once, then never refreshed as document layouts change
• Headcount cut before the exception path is proven, which produces a backlog and a scapegoat
• Every process started at once, so nothing reaches production and nothing can be evaluated

A first four months

Step three is the one that surprises people and it is deliberately placed before any building. Removing a cause of exceptions with a process change, and measuring the effect, tells you the real size of the software problem before you have committed to a solution. Occasionally it tells you there is no software problem left worth solving, which is an uncomfortable finding for a vendor and a good outcome for the buyer.

Before you fund it

• A measured straight-through rate, not an estimated one
• One month of exceptions sorted by cause, with the top three named
• A written acceptance test with a number in it, on held-out real transactions
• Error cost quantified in both directions, and used to set the threshold
• Control design reviewed with internal audit before the build, not after
• An identity and a documented permission scope for every automated actor
• A funded owner for the labeled test set and its refresh
• A benefits case that stands up without the headcount line
• A parallel run covering at least one month-end

Bottom line

Measure the exception rate before anyone quotes you anything, because it is the number that decides both the value and the difficulty. Sort the exceptions by cause and eliminate upstream defects rather than automating around them; that alone often removes a third of the scope. Build the review queue first, treat controls and the audit trail as design requirements rather than paperwork, and write the business case on cycle time and error rate, where the benefits are measurable within a quarter and do not depend on anyone leaving.

Frequently asked questions