You will build a flow that takes invoices from email, extracts the key fields, logs them and files the original.
Every invoice email that reaches the flow should end up as a saved, sensibly named file and a row in your invoice sheet, with the key figures pulled out and checked. Anything missing, wrong or unusual goes to a person instead of being marked as done. The flow combines three things you have already built: inbox routing from Lesson 6.1, "Sort, label and route incoming email", extraction from Lesson 6.2, "Pull data out of invoices, receipts and PDFs", and the file naming habits from Lesson 6.3.
Arif, an invented example, shows why it's worth the effort. At the end of last quarter his boss asked how much the firm had spent with its tile supplier. Answering took him most of an afternoon. He searched through email attachments, a shared folder full of files named "scan001.pdf", and a sheet that was three weeks behind. The information existed, but it was scattered across those places, so nobody could add it up quickly.
Don't trigger the flow on your whole inbox. Use a dedicated trigger: a specific address such as invoices@, or an email label applied by rules, so the flow starts only on invoice emails. Lesson 6.1 shows how to set up either. Arif created an invoices address and asked his main suppliers to send to it. As a backup, he set an email rule that labels anything arriving at the main address with "invoice" in the subject.
Invoice emails don't all look the same. Some carry one PDF, some carry several attachments, and some carry none because the invoice is pasted into the body or sent as a link. Where there are several attachments, use a loop so each file is processed as its own record, as explained in Lesson 2.2. Filter out attachments that aren't PDFs or images, such as the logo in an email signature. An email with no usable attachment goes straight to review.
Save every original file to an invoices folder with a consistent name pattern, for example supplier, invoice date and invoice number. You don't know those fields until extraction has run, so save the file first with a temporary name made from the date received plus the email ID. Once the fields are known, rename the file to the proper pattern.
Next, run the extraction prompt from Lesson 6.2. The fields to extract are supplier, invoice number, date, subtotal, GST and total.
Then have the flow check that the figures add up. This formula check has two parts: the line items should add up to the subtotal, and the subtotal plus GST should equal the total. A failed check can mean a misread figure or a mistake on the invoice itself, and either way a person needs to look.
Each invoice gets a row in the invoice sheet. The row holds all the extracted fields, a link to the saved file, the date received and a status column.
The status is "logged" when every field is present and the check has passed. It is "needs review" when any field is missing, the check has failed, or the supplier is new. A needs-review invoice goes to the review list instead of being logged as done, and the flow sends a notification to the reviewer.
You can add rules of your own. Arif added one: any invoice above an amount set by his boss goes to review regardless of anything else, so a person sees every large payment before it is approved. This follows Lesson 1.3, "Know which work should stay manual", which explains why high-stakes actions keep a human check.
Your test set is ten invoices, including at least one scan, one photo and one two-page invoice. They can be real invoices if your workplace allows it, with sensitive details removed if needed, or sample invoices you make yourself. Include the awkward cases on purpose: the scan, the photo, the two-page invoice, an email with two invoices attached, and an email with no attachment.
Email the invoices to the trigger address one email at a time. For each one, write a line in a test log recording:
what you sent what the flow extracted whether each field matched the document the status the flow gave and why
When you find a fault, fix it and rerun the affected invoice.
Read each review result carefully, because sending an invoice to review is often the flow working correctly. On Arif's first run of ten, six were logged cleanly and four went to review. A photo of a hardware shop receipt went to review because the date was unreadable, which was the right outcome. A scan went to review because its subtotal check failed, and when he looked, the scan was simply blurred, so that was right too. The email with no attachment went to review as designed. The two-page invoice also went to review, but for the wrong reason: extraction had read only page one and missed the total on page two. That was the only fault in the flow. He found a setting in his tool to process all pages, changed it, and reran that invoice.
Three of Arif's four review cases were the flow doing its job, and one was a fault. The review list matters as much as the clean rows. A flow that sends three of ten invoices to a person for good reasons is working. A flow that logs everything, including a blurred invoice with a wrong total, is not working.
Your flow is finished when it has processed all ten test invoices end to end, every invoice has a row with a link to its saved file, and each is marked logged or needs review with a reason recorded for every review. Your test log should show what each invoice needed and whether the flow behaved as intended, and any fault you found should be fixed and the affected invoice rerun.
Before you open the tool, gather your ten test invoices, including the scan, the photo and the two-page one.
Build the invoice flow, process ten test invoices, and record which needed review and why.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).