You will be able to build a flow that takes invoices from email, extracts the key fields, logs them and files the original.
Your flow takes each invoice email, saves the original file under a clear name, reads the key figures, checks them and writes one row to an invoice sheet. If a figure is missing, a sum does not work out or something looks unusual, the invoice goes to a person and is not marked done.
Arif works at a firm that buys from a tile supplier. At the end of last quarter, his boss wanted to know how much the firm had spent with that supplier. The answer took Arif most of an afternoon. He dug through email attachments, a shared folder of files all called "scan001.pdf" and a sheet that was three weeks behind. Everything he needed was there, but it was spread across too many places to total quickly. The flow joins three pieces you built earlier: inbox routing (Lesson 6.1), extraction (Lesson 6.2) and file naming habits (Lesson 6.3).
Point the flow at invoice emails only. Don't run it on the entire inbox. A dedicated trigger limits it this way. It is either an address of its own, such as invoices@, or an email label that rules apply. Lesson 6.1, "Sort, label and route incoming email", covers how to set up both.
Arif set up an invoices address and asked his main suppliers to use it. Some might keep writing to the main address, so he also added a rule there that labels any email with "invoice" in the subject.
Invoice emails arrive in different shapes. One carries a single PDF and another carries several files. Some carry nothing at all, because the supplier pasted the invoice into the message or sent a link. When an email has several files, loop through them so each one becomes a separate record. Lesson 2.2 shows how the loop works. Drop any file that is neither a PDF nor an image, such as a logo in the sender's signature. If no usable attachment is left, send the email directly to review.
Every original file goes into an invoices folder and is named to one pattern, for example supplier, invoice date and invoice number. The flow can't know those details until extraction has run. So give the file a temporary name first, built from the date received and the email ID, and rename it to the full pattern once the fields are known.
Use the extraction prompt from Lesson 6.2, "Pull data out of invoices, receipts and PDFs", to pull out six fields: supplier, invoice number, date, subtotal, GST and total.
Next the flow applies a formula check to those figures. The check tests two things: that the line items sum to the subtotal, and that the subtotal plus GST equals the total. A failed check means either the tool misread a number or the invoice itself contains an error. Both cases need someone to look at the invoice.
Give every invoice a single row in the invoice sheet. The row holds the extracted fields, a link to the saved file, the date the invoice arrived and a status. Mark it "logged" if all fields came through and the check passed. Mark it "needs review" if any field is missing, the check failed or the supplier is new to you. Needs-review invoices go onto the review list and are not recorded as done, and the flow sends the reviewer a notification.
You can add further review rules of your own. Arif's boss chose an amount, and Arif set the flow to send any invoice above it to review whatever the other checks said. A person then sees every large payment before it is approved. Lesson 1.3, "Know which work should stay manual", explains why high-stakes actions like this keep a human check.
Collect ten test invoices. You can use real ones where your workplace permits, with sensitive details taken out if needed, or make sample invoices yourself. Put awkward cases in deliberately: a scan, a photo, a two-page invoice, an email carrying two invoices and an email with no attachment.
Send them to the trigger address one email at a time. Keep a test log with one line per invoice. Each line records what you sent, what the flow extracted, whether each field matched the document, and the status the flow gave and its reason.
When an invoice lands in review, check the reason before you treat it as a problem, because review is often the correct result. In Arif's first run, six of the ten were logged cleanly and four went to review. Three of those four were handled correctly. A photographed receipt from a hardware shop went to review because its date could not be read. A scan failed the subtotal check, and a closer look showed it was blurred. The email without an attachment went to review as designed.
The fourth was the two-page invoice, and it went to review for the wrong reason. Extraction had read only page one and missed the total on page two. This was the only fault in Arif's flow. His tool had a setting to process all pages, so he changed it and ran that invoice again.
Give the review list as much attention as the clean rows. A flow that sends three of ten invoices to a person for sound reasons is working. A flow that logs every invoice, including a blurred one with a wrong total, is not working. Whenever you find a fault, fix it and rerun the invoice it affected.
The flow is complete when you can confirm each of these:
All ten test invoices have gone through the flow end to end. Every invoice has a row in the sheet with a link to its saved file. Each invoice is marked logged or needs review. Every invoice sent to review has its reason recorded. The test log shows what each invoice needed and whether the flow behaved as intended. Any fault you found has been 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, run ten test invoices through it, and note which ones needed review and why.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).