What 'Set Checks' Mean in Invoice Automation (and Who Decides Them)

What a set check is

When invoices are extracted into a spreadsheet or an import file, someone has to decide what "looks right" means. In our work that decision is written down as a list of checks, and the customer owns the list.

Typical checks on a purchase invoice:

• Line math: quantity × rate equals the line amount.
• Tax math: the tax on each line, or on the invoice, matches the stated rate.
• GSTIN format: the number has the right structure and length.
• State code: the first two digits of the GSTIN agree with the state shown on the invoice.
• Total check: line amounts plus tax add up to the invoice total.

Each of these is a rule a script can run on every invoice, every time. Nothing about it is a guess.

A percentage needs a denominator

You will see claims like "99% of invoices pass." On its own that sentence is hard to use. Pass what? Checked against what?

A percentage is meaningful only against the checks behind it. "50 of 50 invoices passed all set checks" tells you something specific: those 50 invoices passed each test on the list. It says nothing about tests that were not on the list.

If a tool shows you a single number or score, ask what sits underneath it. A score with no list of checks behind it is hard to act on.

Failures should have names

When a check fails, we think the report should say which one. "GST check failed" or "line total does not match" is something a clerk can open the invoice and resolve in a minute.

A bare score, such as "invoice 7 scored lower than the rest," gives your team nothing to act on. They have to re-read the whole invoice to find what the tool was unhappy about.

So the useful output is a list: invoice number, check name, the value found and the value expected. That is what a reviewer needs.

What is not checked

This part matters, so we will say it plainly. Anything that was not set as a check is not checked.

For example, suppose a vendor slips extra terms and conditions into the footer of an invoice. If "terms and conditions text" is not one of your checks, the script will not notice. It was not asked to.

That is not a flaw hidden in the system. It is how rule-based checking works: it does what was defined. And it is easy to fix once you know you want it. If you tell us you want a check on payment terms, or on a particular clause, it can be added as another rule. The point is that you decide, with eyes open, what is on the list.

A reasonable way to build the list:

1. Start with the errors your team has actually caught in the past.
2. Add the checks your clients or auditors expect.
3. Review the list after the first few weeks of real runs and add what you missed.

How this fits a weekly run

Our usual setup is one script per workflow, written once around your invoice layouts and your checks, then run every week on your own computer. The checks live in that script. When your needs change, the list changes, and you know exactly what the next run will test.

If you want to see what a checks list could look like for your own invoices, you can show us your workflow and we will tell you honestly what can and cannot be covered. Field count and a sample belong in the document automation assessment.

FAQ

What are set checks in invoice automation?

Set checks are specific tests agreed in advance, such as line math, tax math, GSTIN format or state code. The script runs them on every invoice and reports each failure by name.

Can an invoice pass and still contain an error?

Yes. An invoice passes when it clears the checks that were defined. An issue outside those checks, such as changed fine print, is not caught unless that check is added.

Can more checks be added later?

Yes. A new rule can be added to the script when you ask for it. We agree the new check with you first, so you know what each run tests.