The automation itself. It reads the documents, applies your rules, asks a person when it is unsure, writes the result into your systems, and keeps a record of every decision. Built by a software company, tested against your real cases, and handed over with the code.
This is for you if
Services
A first process usually takes six to twelve weeks. The long part is never the clever bit. It is the exceptions, the integration and the testing.
Every rule, including what happens when the numbers do not match, when a document is missing, when the supplier is new, and when two people disagree. Signed off before anyone writes code. Arguments here are cheap and arguments in month three are not.
What it reads, what it writes, what it must never touch, and what it does when one of your systems is down for an hour. Written as a diagram your own IT team can review and object to before we start.
Pull the fields out of the paperwork and attach a confidence score to each one. Anything the system is unsure about is sent to a person instead of guessed. That threshold is a setting, so you can make it more or less cautious later.
Your decision rules go in a table, not buried inside code. When a tolerance changes from two percent to three, someone in your finance team changes a number. They do not raise a ticket and wait a fortnight.
A queue showing the document, what the system read, why it is unsure, and the options. Approve, correct or reject in one click. Every correction is stored, so you can see what it keeps getting wrong.
Through a proper integration where one exists. Where it does not, we will say so and price the alternative honestly, because software that clicks through screens breaks every time your supplier changes their layout.
We replay real cases from the past year and compare what the system decides against what actually happened. Where they differ we find out which one was right. This is the only test that means anything.
What came in, what the system read, what it decided, why, who approved it and when. Kept in a form an auditor can be shown. If you cannot explain a decision six months later, you do not really have a system.
For a few weeks it processes everything but changes nothing. You compare its output against what your team did. Only when the two agree consistently does it start acting on its own.
Code in your repository, written instructions, a guide for what to do when it breaks at midnight, and training for whoever owns it. You should be able to change suppliers without changing systems.
Describe one process on a call and we will tell you what it would take to build it.
Our stack
You do not need to know any of these. They are listed so your IT team can see what would end up in your systems, and check that none of it is unusual.
Example
This is the same supplier invoice process, followed step by step. It is worth reading because almost every question about cost and risk lands on one of these ten steps.
ExampleThe system watches the accounts inbox, saves the attachment, and records where it came from. Nothing is deleted, so the original is always there to go back to.
Supplier, invoice number, date, currency, line items, tax and total. Each field gets a confidence score. Here the total scores 99% and the purchase order number scores 71%.
The name on the invoice rarely matches your master list exactly. It is matched on tax number and bank details rather than name, because names are written differently every time.
Three way matching. Ordered 500 units, received 480, invoiced for 500. The system finds the difference rather than a person finding it three weeks later.
The quantity does not match, and the purchase order number was only read with 71% confidence. Your rules say anything under 85% goes to a person, so it joins the review queue instead of being guessed at.
Your clerk sees the invoice, the order, the delivery note and the two problems side by side. She corrects the purchase order number and confirms the short delivery was agreed by phone. Two clicks, and both are recorded against her name.
Her correction is stored as a labelled example. When the same layout appears again next month, that field is read correctly. The system gets better because she did her job, not because someone retrained it.
Posted with the correct cost centre and tax code. If the ERP rejects it, the automation does not retry blindly. It stops and tells someone.
Under your threshold it goes straight through. Over it, to the department head. The rule sits in the table your finance team can edit.
Six months on, an auditor asks why this invoice was paid short. One search shows the original email, what was read, what did not match, who approved it, when and why.
An example, with invented figures, to show how the pieces fit together. Your process, rules and thresholds will be different.
FAQ
Six to twelve weeks for most. What moves it is the number of exceptions and whether your systems have a proper way in. The second process is always faster because the surrounding parts already exist.
On the processes we usually build, it takes the repetitive part and leaves the judgement. The people who did the typing end up handling the exceptions. We will not tell you nobody's job ever changes, but a system that removes the review step is one nobody trusts.
It should stop rather than guess. Anything below your confidence threshold goes to a person. When something genuinely wrong gets through, the record shows what it read and why it decided that, so it can be fixed rather than argued about.
No. It can run in your own environment. It costs a little more to set up and some document readers are only available as cloud services, in which case we will tell you what the alternatives are.
You do. Code in your repository from the first week, not delivered at the end. No part of it is locked to us.
Often, yes. Many clients have a platform that does part of this and stalls on the integration or the exceptions. We are happy to build only the missing part rather than sell you a replacement.
Next step
What comes in, what your team does with it, where it ends up, and which part causes the arguments. That is enough for us to say on the call whether this is a build, a smaller fix, or something you should not automate at all.
Ahmedabad, India. We work with teams in the US, UK, Europe, Singapore and the Gulf, and we are used to the time difference.