First of all, who decides how an invoice gets posted
Posting a supplier invoice follows accounting rules, which account, which VAT code, which cost center, and those rules are decided by your practice or by your back office, not by whoever builds the automation
Muffin Suite writes into the system the rules you have dictated to you by the people who know them, then the system runs them always the same way, it doesn't invent them and it doesn't guess when it meets a case nobody had planned for
This is the first step because it's the one that always gets skipped, people start from the software and halfway through they notice that nobody had written down what to do with shipping invoices or with credit notes
Where the invoices come in from
Supplier invoices come into a company through several doors, and the first thing to do is line them up in one place
There are the XML files of the e-invoice, the ones you download from the tax portal or the ones your practice forwards to you, there are the PDFs attached to emails, there are the documents you download from a supplier's portal, and every so often there is still paper that somebody scans
An automation can collect from all of those doors, but each one has to be looked at first, because the emails come in a different shape from every supplier and portals move their buttons every now and then
How the document gets read
The format a supplier invoice arrives in is the biggest difference in the whole procedure, and knowing which one you have in your hands is worth it if only to follow what you're being told when somebody offers to automate the posting
The XML of an e-invoice is a tidy file, the fields have names, the taxable amount sits where it has to sit, and reading it is reliable, there is no interpretation in the middle, and if you want the detail there is the guide on what can be automated starting from the XML
A PDF, on the other hand, has to be interpreted, and not all PDFs are the same, the one born on a computer has the text inside it already and the exact value gets pulled out, the scanned one is a photograph and has to be read, with the skew, the stamps over the numbers, the tables with no lines
In a PDF the totals are the easy part, they almost always sit in the same spot of that supplier's layout, the detail lines are the hard part because there is a varying number of them and every so often they wrap onto the next line
The approach that holds up is to learn each supplier's layout, which stays the same anyway, and never to read a value by fixed position when you can read it by its label
The checks, which are the part that really counts
An automation that reads well and writes straight away is a machine for doing damage fast, what makes it useful are the checks that sit between the reading and the writing
The first check is on the supplier, the VAT number has to match a record that already exists, and if it doesn't exist the system doesn't invent one, it stops and asks you what to do
The second is the arithmetic, the taxable amounts plus the VAT have to make the document total, and if they don't it means something was read wrong, it's the best safety net there is because it doesn't depend on how good the scan looks
The third is the comparison against what you had ordered or against the delivery note (DDT) that came in, prices, quantities, codes, and here the automation does the work nobody does by hand because there are too many lines
Say, just to show the reasoning with numbers made up here, that you ordered a hundred pieces, ninety-eight turned up and you get invoiced for a hundred, by hand you find that difference only if you feel like checking line by line, the machine finds it every time because it doesn't get tired at line four hundred
The fourth check is the duplicate, and it has to be built properly, the same invoice can arrive twice, by email and as XML, and posting it twice is worse than not posting it at all, which is why you keep track of what has already been done instead of trusting the eye
Writing it into your business software
Once the checks have passed, the system opens your business software and fills in the fields the way the person who does it today would, same screen, same sequence, same result
If your business software has a direct integration we use it, because it's more solid, if it hasn't we go through the screens and the work gets done all the same, and that's the house specialty
At the end of every posting there is a written record of what was done and when, so the next morning you don't have to trust it, you look
What doesn't get through, and ends up in the queue
An invoice with something wrong on it shouldn't be posted anyway, it has to stop
Into the queue go the supplier who isn't in your records, the total that doesn't add up, the price that differs from the one on the order, the document that looks like a duplicate, the layout the system no longer recognizes because the supplier changed it
That queue isn't a failure, it's the point where the work passes through a person, and the work left to them is looking at the real cases instead of retyping two hundred invoices that were all alike
If you want to know whether your case holds up
It takes very little to say anything sensible, which doors the invoices reach you through, how many there are in a month, and five or six sample documents, made-up ones are fine, including the supplier who writes the amounts their own way
From there you can see straight away how much of it is mechanical and how much is the queue of cases to look at, and without that step anybody who tells you how long it takes is guessing