Calculating Document-Automation ROI Without Fooling Yourself

An illustrative sales formula often looks like this. The figures below demonstrate how to challenge assumptions; they are not PM INNOSOFT results or benchmarks for a real engagement:

5 staff × 4 hours/day × 22 days × 300 baht/hour = 132,000 baht/month The system removes 80% of the work → saves 105,600 baht/month The system costs 30,000 baht/month → pays back in the first month

The figures may still be misleading even when the arithmetic is correct, because the assumptions may not match the real workflow.

This article walks through where it breaks, then offers a way of thinking that produces a much smaller final number — but one you can defend in a meeting and audit afterwards.

Problem 1 — Time saved is not money saved

This is the largest and most common error.

Suppose the system genuinely removes 3 hours a day of keying from each of 5 accounting staff. The question is:

Did the company's costs actually fall?

If nobody was let go, no position was closed, and the same salaries are still paid — the company's costs did not fall by a single baht.

The 15 hours a day you got back are valuable, but they are not "money saved". They are "capacity freed up", and that becomes value only when it is spent on something that creates value.

An ROI presentation that converts hours directly into money is dismissed immediately by an experienced CFO, because they know next year's payroll budget will not fall by that figure.

A way of counting that holds up

Be explicit about how the recovered time turns into value. There are only three forms, and you have to pick the one that matches your reality.

Form 1 — Avoided hiring (counts fully as money) If transaction volume is growing and you planned to hire 2 more people next year, and the system means you do not have to, that is real money not spent, and it is the strongest form to present.

Form 2 — Reduced overtime (counts fully as money) If the accounting team works overtime every month-end to close, and the system removes the need, look at 12 months of overtime claims. This figure is auditable against the actual accounts, which makes it very credible.

Form 3 — Time redirected to higher-value work (cannot be counted as money, but must be mentioned) For instance, the accounting team gets time for cost analysis they never had time to do. This is genuinely valuable and cannot be reduced to a number. Present it separately as a qualitative benefit and do not stuff it into the ROI figure.

Separating the three makes a proposal more credible immediately, because it shows the person presenting understands which benefits are money and which are not.

Problem 2 — The 80% that never happens

The sales formula usually assumes 80% of the work disappears, on the basis that "if the system reads 80% then 80% of the work is gone".

But document work is not only keying. Break it down.

If keying is 50% of total time and the system removes 80% of that, the real saving is 40%, not 80%.

And it does not end there, because "reviewing" does not disappear — it changes shape, from checking what you keyed yourself to checking what the system read. For the first three months that usually takes longer than before, because the team does not trust the system yet and opens every document even when the system says it is confident.

Do not replace an inflated number with another generic benchmark. Time each step before and after using the same document mix, workload, and team to produce a figure that belongs to that organization.

Problem 3 — Three costs missing from the formula

The monthly system fee is not the whole cost, and these three are what most often push a project over budget.

Cost 1 — Your own people's time during implementation

The system has to learn your document layouts. Someone has to say which field is which, test it, and correct it. That work lands on the person who knows the job best, who is always the busiest person.

Name the responsible people, hours, and implementation period from the actual project plan, then value that time using actual compensation. Do not use a generic percentage instead of resource planning.

This cost almost never appears in a vendor proposal, because it is not money paid to the vendor. It is still a real cost to the company.

Cost 2 — The dip in productivity

For the first two to three months the team works more slowly, because they are running two systems in parallel, learning a new process, and double-checking because they do not trust it yet.

This is not a sign the project is failing. It is normal, and it should be in the budget from the start. Projects that did not allow for it get declared a failure in month two, while they are in fact proceeding exactly as expected.

Cost 3 — Ongoing care

New suppliers bring new layouts. Tax rules change. The accounting system gets upgraded. All of it needs someone to adjust the configuration.

With nobody looking after it, the system reads a little worse each month with nobody noticing, until one day the team is back to keying everything by hand and no one ever announced the project had ended.

Maintenance must be estimated from document variety, change frequency, monitoring scope, and actual ownership rather than applying one percentage to every organization.

A formula that works

Annual benefit =
    (hiring avoided)
  + (reduced overtime, from actual claims)
  + (reduced cost of errors)          <- see below

First-year cost =
    (12 months of system fees)
  + (implementation and initial setup)
  + (your own staff time x actual salary)
  + (productivity dip: about 1 month of the involved team's salary)
  + (maintenance based on actual scope and plan)

First-year ROI = (benefit - cost) / cost

Reduced cost of errors is the piece most often forgotten, though in some organizations it is the largest. Calculate it from:

• Number of wrong or duplicate payments last year × average value × the share caused by keying errors
• Penalties or interest from incorrect or late tax filings
• Time spent tracking down errors at close × number of months

These figures come from your actual accounts, so no guessing is involved — and because they come from the accounts, they are the strongest numbers in the whole proposal.

How to measure the time actually spent, before calculating anything

Every figure above is meaningless if the starting point is a guess, and the answer you get from asking "how many hours do you spend keying documents?" is usually well off — people under-report, because they do not count the time spent finding missing documents, querying suppliers, and fixing errors.

A method that gives a real number within two weeks: have the team record actual times in the simplest possible way — start time, end time, what they were doing. Paper or a spreadsheet is fine. No system needed.

Record for two weeks spanning both the start of the month and month-end, because the volumes differ sharply, then take a weighted average.

What this usually reveals: most of the time is not spent keying. It is spent looking for documents and correcting errors — which changes the problem the project is trying to solve, and sometimes leads to the conclusion that tidying up the document intake process fixes it without buying any system at all.

A simple decision rule

If you would rather not build a complex model, use this:

Signs it is worth it regardless of volume: you are planning to hire because of document volume · you pay overtime at every close · you have paid wrong or duplicate invoices because of keying errors · or you regularly close late.

Signs to wait: you are changing ERP next year — wait until that is done, or you will do this twice · your document formats are about to change · or nobody in the organization is available to own the system.

The final trap: a number that looks too good

If the payback period looks unusually short, recheck the assumptions, internal effort, learning period, and ongoing care. There is no defensible universal payback range for document automation: workload, data quality, review process, labour cost, existing systems, and scope differ by organization.

What to do instead: decide before you start what you will measure, when, and who does it. Then actually measure at month 6 and month 12. The result will not match the estimate — that is normal. What matters is knowing where it diverged, so the next project can be estimated better.

In short

An honestly calculated ROI is always smaller than the vendor's. It is also the one that survives the CFO's review, and the one still standing in month 12 when someone asks whether the project was worth it.

Three principles: time saved is not money until it becomes avoided hiring or reduced overtime · your own staff time and the productivity dip have to be counted · and the time actually spent has to be measured, not guessed at.

Before calculating ROI, find out how well your documents can actually be read — if they read poorly, every figure above is meaningless. Send sample documents for assessment. The team confirms the method, queue, timing, and fees before work begins.

Read next: AI-OCR for accounting and finance · Why 95% accuracy is not enough