Automating invoice processing in Make, step by step

Invoices arrive by email, someone downloads them, renames them, files them in the right folder, types the amounts into a spreadsheet and tells accounting. Every single one takes a few minutes. Multiply that by a month and you have a part-time job nobody put on the org chart.

Most of this can run without anyone touching it, in an afternoon, without writing code. Here is how to do it in Make, and, more importantly, which parts people skip and then wonder why the flow cannot be trusted.

What the flow does

1. Watches a mailbox for messages with attachments.
2. Recognises which attachments are invoices.
3. Extracts the supplier, number, date and amount.
4. Renames the file to a consistent convention.
5. Files it in storage, in a folder per month.
6. Appends a row to a register.
7. Posts one daily summary rather than a ping per invoice.

Building it

1. The trigger

A watch module on the mailbox, filtered to messages that actually have attachments. Use a dedicated address or a label, not the main inbox. Pointing an automation at a mailbox that also receives everything else is how you end up with a register full of newsletters.

2. Recognising an invoice

A filter on file type and name gets you most of the way. For the rest, a language model reading the first page is more reliable than a regular expression, because suppliers name files whatever they like.

3. Extracting the data

This is the step where quality is decided. Validate against a schema: the amount has to be a number, the date a date, the invoice number non-empty. Anything that fails validation goes to a review queue rather than into the register. A flow that silently writes nonsense is worse than no flow, because you stop checking.

4. Naming and filing

One convention, applied without exception, for example 2026-08-14_supplier_number.pdf. The point of a convention is not tidiness, it is being able to find a document in three years without opening twenty files.

5. The register

A spreadsheet is fine to start with. Make it idempotent: before appending, check whether that invoice number from that supplier already exists. Without this, one re-run of the scenario gives you every invoice twice, and that is the single most common way these flows lose trust.

6. Notifications

One daily summary, not a message per invoice. Automation that generates more noise than the manual process it replaced gets muted, and a muted flow is an unmonitored flow.

The parts people skip

• Error handling. Every step needs defined behaviour on failure: retry, queue, alert. Make will not do this for you.
• Duplicates. Covered above, and worth repeating, because it is the failure that quietly destroys confidence in the numbers.
• The review queue. Roughly one invoice in twenty will be odd. Plan for where it goes, or it will end up in the register wrong.
• Monitoring. Suppliers change their templates. You want to hear about that from an alert, not from your accountant.

When Make is the wrong tool

At low volume and with a simple flow, Make is fast and cheap. Once you are processing a large number of documents, need real audit trails, or the logic starts branching in every direction, the maintenance cost of a visual scenario overtakes the cost of writing the same thing in code. That is a judgement call worth making at design time rather than after the second rebuild.

Want to walk through this on a real example from your company? Get in touch and we will map the flow for your case, including telling you if a spreadsheet and ten minutes a week is genuinely the better answer.