**Assumption:** the current purchase-order register is accessible in **Excel and/or SharePoint** and contains at minimum PO number, supplier, ordered lines/quantities and expected amounts. If it does not, that is a dependency to acquire; invoice-to-PO matching must remain manual until an authoritative PO dataset exists. A second dependency must be confirmed before deployment: whether the existing **Zapier → Xero** connection can search existing bills and create a bill in a non-payable/draft state. If either operation is unavailable, the corresponding Xero lookup or upload remains manual. # 1. Definition of done An invoice is **correctly completed** only when every condition below is true. 1. **The source is preserved.** * The original invoice attachment exists in SharePoint. * Its control record contains the Outlook message ID and SharePoint file ID/link. * Exactly one control record exists for that Outlook message ID. 2. **The minimum accounting fields are present.** * Supplier. * Supplier invoice number. * Invoice date. * Gross amount. * VAT amount where applicable. * PO number. * Currency. * These values are stored as structured fields in the SharePoint control register. Because no invoice-parsing/OCR tool is listed, these fields are **entered or confirmed by finance manually**. Zapier must not infer them from PDF text. 3. **A single PO candidate has been identified.** * PO number exists. * Supplier on PO equals supplier selected for invoice. * There is exactly one intended PO record, or a finance user explicitly resolves the ambiguity. 4. **The financial match passes.** * Invoice amount and PO-supported amount agree at the configured control level. * Default tolerance is **£0** until finance documents another tolerance rule. * Any freight, surcharge, quantity, tax or price difference goes to exception handling rather than being silently accepted. 5. **The duplicate controls pass.** * No existing control record has the same normalized supplier + normalized invoice number. * No existing Xero bill has the same supplier + normalized invoice number, where Zapier can perform that search. * A secondary warning is raised for the same supplier + same gross amount + nearby invoice date even when the invoice number differs. 6. **The source identity control passes.** * Sender address/domain corresponds to the supplier mapping maintained in SharePoint. * A previously unseen supplier email domain cannot proceed automatically. 7. **Payment-detail risk has been checked manually.** * The approver visually compares payment details/change instructions on the invoice against the supplier's last approved invoice or other trusted existing record. * Any changed payment instruction blocks release. * Because there is no trusted supplier-portal API or bank-detail verification source in the toolset, **bank-detail verification is deliberately not automated**. 8. **A human release exists.** * An identified finance approver records approval. * Approval timestamp is stored. * The person approving an exception is not the same person who made the corrective amendment that resolved it. 9. **Only then may Xero be touched.** * The bill is created once. * The returned Xero bill ID is stored. * Supplier, invoice reference, date and amount in Xero equal the approved control record. * The automation does **not** approve the bill for payment or make payment. 10. **The circuit closes.** * SharePoint record contains the Xero ID and final state. * No unresolved warning remains. * A person or script can verify all of the above from the control record, SharePoint invoice and Xero bill in under one minute. --- # 2. The map The circuit uses six states. These exact state names carry through the rest of the design. **S1 — Captured & Registered** Outlook invoice is preserved in SharePoint and receives one immutable control record. ↓ **S2 — Match Candidate Built** Finance-confirmed invoice metadata is associated with one candidate PO. ↓ **S3 — Controls Executed** PO match, duplicate controls and supplier-source controls run. ↓ **S4 — Human Release Verified** A finance approver checks the invoice package, fraud-sensitive elements and all machine results. ↓ **S6 — Posted & Closed** Only after S4 approval, the bill is created in Xero, the returned record is reconciled against the approved input, and the circuit closes. Any failure in S1–S4 or uncertainty during Xero creation diverts to: **S5 — Exception & Corrective Loop** S5 either returns the invoice to the appropriate earlier state with changed information or ends in manual escalation. The normal route is therefore: **S1 → S2 → S3 → S4 → S6** The controlled detour is: **S1/S2/S3/S4/S6 → S5 → appropriate prior state** There is deliberately **no S5 → S6 shortcut**. --- # 3. Each step | State | Context needed | Allowed tools | Expected output | Proof of success | | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **S1 — Captured & Registered** | Outlook message ID, sender, received timestamp, attachment, attachment filename | Outlook, Zapier, SharePoint | Original attachment stored; one SharePoint control record created with a unique internal control ID | Search by Outlook message ID returns exactly one control record; SharePoint attachment opens; control ID is populated | | **S2 — Match Candidate Built** | S1 record; manually confirmed supplier, invoice number, invoice date, gross, VAT, currency and PO number; PO register | SharePoint, Excel, Zapier | One candidate PO is attached to the control record, or the item is explicitly marked `PO_NOT_UNIQUE` / `PO_NOT_FOUND` | PO lookup returns exactly one record whose PO number and supplier equal the structured invoice fields | | **S3 — Controls Executed** | S2 record; candidate PO; existing SharePoint invoice records; supplier/domain control list; Xero bills if searchable through Zapier | SharePoint, Excel, Zapier, Xero where supported | Machine control results for PO match, duplicate detection, sender/domain and secondary duplicate warning | Every configured control has an explicit `PASS`, `FAIL` or `UNAVAILABLE`; no blank/null control can be treated as PASS | | **S4 — Human Release Verified** | Original invoice; S3 results; PO; last approved supplier invoice/control history; exception history if any | SharePoint, Excel, Outlook, Xero for manual comparison where needed | Named finance approver either records `APPROVED_FOR_UPLOAD` or `REJECTED/EXCEPTION`; fraud-sensitive checks are explicitly acknowledged | Approver identity + timestamp + required check fields exist; all S3 controls are PASS; no unresolved flag exists; exception approver differs from the person making the correction | | **S5 — Exception & Corrective Loop** | Failing state, failed control, original evidence, attempt count, previous values and error response | Outlook, SharePoint, Excel, Zapier, Xero only for verification/search | Either a corrected input sufficient to return to an earlier state or an explicit manual escalation | Exception record identifies original state, failure code, old value, changed value/action, responsible person and next state; attempt counter increments | | **S6 — Posted & Closed** | S4 approval token/record; approved invoice fields; pre-create Xero duplicate recheck | Zapier, Xero, SharePoint | Exactly one Xero bill plus closed SharePoint control record; bill remains outside automated payment execution | Xero bill ID is present; Xero supplier/reference/date/amount equal S4 approved values; Xero search finds one intended bill for that supplier/invoice reference; SharePoint final state is S6 | ### Important implementation boundary The system can automate **transport and deterministic comparison**. It should not pretend to automate document understanding with the tools provided. With Outlook, SharePoint, Excel, Xero and Zapier alone, I would **not automate extraction of supplier, invoice number, PO reference, amount or bank details from arbitrary PDF invoices**. Those fields should remain human-confirmed unless a document-parsing capability is later acquired and independently tested. --- # 4. Transitions ### **S1 — Captured & Registered → S2 — Match Candidate Built** Move forward only when: * SharePoint copy exists. * Control record exists exactly once. * Required accounting metadata has been confirmed. Detour to **S5** when: * Attachment cannot be stored. * Same Outlook message ID already exists. * Invoice attachment is missing. * Required accounting metadata is incomplete. * File cannot be opened. A second copy of the same Outlook email is not a retry candidate; it is closed as an intake duplicate. ### **S2 — Match Candidate Built → S3 — Controls Executed** Move forward only when: * PO number resolves to exactly one intended PO. * Supplier on that PO equals the structured invoice supplier. Detour to **S5** when: * PO does not exist. * Multiple PO records satisfy the lookup. * Supplier differs. * Invoice has no PO where the process requires one. * PO data required for comparison is missing. Do not guess the PO from invoice amount, supplier name or historical behaviour. ### **S3 — Controls Executed → S4 — Human Release Verified** Move forward only when all mandatory deterministic controls are `PASS`. These include: * PO identity. * PO financial match. * Primary duplicate search. * Supplier/source identity. * Required-data completeness. A secondary duplicate warning must be explicitly dismissed by a person before moving to S4 approval. Detour to **S5** when: * Amount/quantity/tax comparison fails. * Existing supplier/invoice-number match is found. * Sender/domain is not recognised. * Xero duplicate check is unavailable when it is required. * Any control returns `UNKNOWN`, `ERROR`, blank or timeout. **Unknown never means pass.** ### **S4 — Human Release Verified → S6 — Posted & Closed** Before Xero creation, perform one final duplicate lookup using the approved supplier and invoice number. Move forward only when: * Named human approval exists. * Approval occurred after the most recent data change. * Fraud-sensitive review is complete. * No duplicate is found during the final pre-create check. Detour to **S5** if: * Invoice or PO changes after approval. * Bank/payment instructions differ from established supplier information. * Approver rejects it. * Duplicate appears after the original S3 check. * Approval is stale because a controlled field changed. Any edit to **supplier, invoice number, PO, amount, invoice date, VAT or currency invalidates the prior approval**. ### **S6 posting transition** Xero creation must be treated as a potentially ambiguous write. If Xero/Zapier says the create operation timed out: **Do not immediately retry the creation.** Go to **S5** and first search Xero for the approved supplier/invoice reference. * Existing correct bill found → reconcile it and resume S6. * No bill found → one controlled creation retry may be permitted. * Multiple candidates found → manual escalation. This prevents the classic failure where Xero successfully creates the bill but Zapier loses the response and creates it again on retry. --- # 5. Failure return S5 is not a generic "try again" bucket. Every return must modify either the **input, evidence or execution path**. ### Failure originating in S1 **Examples:** file-save failure, missing attachment, incomplete mandatory fields. **Return to:** S1. **Information carried back:** * Control ID. * Outlook message ID. * Failure code. * Attachment/file reference. * Attempt number. * Connector error if applicable. **What must change:** * A transient SharePoint/Outlook failure gets one fresh connector attempt. * Missing metadata requires manual entry. * A missing invoice attachment requires human handling. The same unchanged attachment operation is not repeated indefinitely. ### Failure originating in S2 **Examples:** PO missing, wrong supplier, multiple PO candidates. **Return to:** S2. **Information carried back:** * Invoice supplier and PO number. * Candidate PO results. * Exact reason candidate selection failed. **What must change:** * Finance corrects the PO reference, or * finance resolves which PO is intended, or * the invoice is formally classified as an allowed non-PO invoice. The automation may not select a "closest" PO. ### Failure originating in S3 **Examples:** amount mismatch, duplicate, unknown sender. For a correctable PO/invoice-data problem: **Return to:** S2 after a person corrects structured metadata or PO data. The S3 results are discarded and recomputed from the new data. For an actual duplicate: **No automatic retry.** The item stays in **S5** until finance records disposition such as: * duplicate — do not upload; * credit/reissue expected; * investigation required. For an unrecognised supplier domain or suspected fraud: **No automatic retry.** A human must establish legitimacy before the record can return to S3. ### Failure originating in S4 **Examples:** payment details changed, approver rejects, invoice altered after review. **Return to:** * S3 if underlying machine-checkable data changed; * S4 only if the issue concerned missing human evidence and no controlled data changed; * remain in S5 if fraud remains unresolved. Approval is never carried across an invoice-value change. ### Failure during S6 **Examples:** Xero timeout, Zapier timeout, partial response. **Return to:** S5. Carry back: * Internal control ID. * Approved supplier/invoice number. * exact Xero create payload values. * timestamp. * returned Xero/Zapier error. * attempt counter. The next action changes from **create** to **search/reconcile**. Only after proving that no corresponding bill exists may another create request be issued. That distinction is one of the most important controls in the circuit. --- # 6. Limits The workload is approximately **180 invoices/month**, or roughly 8–9 invoices per working day in a typical month. The circuit should therefore be deliberately small-volume and conservative. ### **Retry ceiling** * Connector/read error: **1 automatic retry**. * Corrected-data cycle: **1 return through the affected validation state** before requiring finance review. * Xero create operation: **maximum one initial create plus one create retry**, and the retry is permitted only after a Xero search proves that the first create did not succeed. * Duplicate suspicion: **0 automatic retries**. * Fraud/source-identity failure: **0 automatic retries**. ### **Backlog ceiling** At more than **30 unresolved invoices**, suspend automatic Xero creation. Thirty items represent roughly three to four normal working days of invoices. At that point the likely problem is systemic rather than an isolated exception. Intake may continue, but nothing progresses automatically into Xero until finance reviews the backlog. ### **Volume anomaly ceiling** If intake exceeds either: * **30 invoices in one business day**, or * **250 invoices in a rolling 30-day period**, flag a volume anomaly before processing the excess automatically. This protects against Outlook loops, duplicate forwarding rules and unusually large imports masquerading as normal work. Finance may release the queue after confirming that the volume is legitimate. ### **Age ceiling** Any invoice that has not reached S6 within **3 business days** becomes visible on an exception list. Any unresolved invoice still open **3 business days before month-end** receives mandatory finance review, because the stated unacceptable failure specifically includes an error remaining unnoticed through month close. ### **Automation-cost ceiling** Design the Zapier circuit for no more than approximately **10 charged automation actions per normal invoice**. At 180 invoices/month that is approximately: **1,800 actions/month + 20% retry/exception headroom = 2,160 actions/month.** If the actual Zapier plan prices that workload above the company's acceptable operating cost, simplify the workflow rather than adding more automation. ### **Processing boundary** Never bulk-create more than **30 Xero bills from one unattended queue release**. That limits blast radius if a mapping or workflow configuration is wrong. ### **Failure-rate stop** Suspend automatic Xero creation if, over any 20 consecutive invoices: * more than 4 enter S5 because of a technical/control failure, or * 2 or more Xero create operations return ambiguous results. That is evidence that the circuit itself needs investigation. --- # 7. Human brake The payment process itself is **outside this automation**. Zapier must never approve or pay a Xero bill. | Action | Why it needs approval | What the approver checks | | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **Release an invoice for Xero upload** | Creates a financial liability inside the accounting environment | Original invoice matches supplier, PO and structured values; all S3 controls passed; invoice is expected | | **Accept any PO price/quantity/tax/freight difference** | An exception can conceal overbilling or a deliberately manipulated invoice | Exact difference; business reason; PO terms; whether a corrected PO or supplier credit is required | | **Accept an invoice without a valid PO** | Removes the primary purchase authorisation control | Why no PO exists; who authorised the purchase; cost centre/accounting treatment | | **Process an invoice from a new or changed sender/domain** | Fraudulent supplier-email impersonation is a common route around PO matching | Previously known supplier correspondence; whether domain is established; independent legitimacy evidence | | **Accept changed bank/payment instructions** | Direct route to fraudulent payment | Compare with previously approved supplier information; obtain independent supplier verification before release if different | | **Override a duplicate warning** | Directly conflicts with the stated unacceptable failure | Prior invoice number, date, amount and Xero record; documentary evidence that the second document is genuinely different | | **Correct supplier, PO, invoice number or amount after validation** | Changes the basis on which controls ran | Source document supports the correction; previous approval has been invalidated; controls rerun | | **Proceed after an ambiguous Xero write** | Retrying a successful-but-unacknowledged write can create a duplicate | Search Xero first; determine whether a bill already exists; compare Xero ID/reference/amount | | **Approve or make payment in Xero** | This is where a fraudulent or duplicate bill becomes an actual cash loss | Payment batch, supplier, bank destination, invoice support, duplicate status and appropriate payment authority | | **Send an external supplier query** | External communications can confirm information to an attacker or create commercial commitments | Correct recipient from established records; minimum necessary information; no acceptance of changed bank details based solely on email reply | ### Separation of duties For ordinary exact-match invoices, one finance approver after S3 is acceptable. For any **S5 exception involving supplier identity, bank details, duplicate status, or financial mismatch**, the person who resolves the exception may not be the sole person approving release. With three finance staff, this provides a workable two-person control without requiring two-person review of all 180 invoices. --- # 8. Test cases | Case | Input | Expected behaviour | Result | Why | | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **1 — Normal PO invoice** | Known supplier; invoice `INV-4821`; £4,860; PO `PO-7612`; invoice values match PO; established sender domain; no prior invoice number | S1 registers once → S2 finds one PO → S3 controls pass → S4 human reviews and approves → final Xero duplicate check → S6 creates one bill and reconciles its values | **PASS** | The circuit permits a clean invoice only after deterministic controls and human release | | **2 — Obvious duplicate resend** | Supplier forwards the identical invoice two days later from the same email thread | S1 creates/locates intake evidence; S3 finds existing normalized supplier + invoice number; routes to S5; no Xero creation | **PASS — rejected** | A resend cannot become a second payable bill | | **3 — Legitimate amount mismatch** | Invoice says £7,425; PO supports £7,400 because supplier added £25 carriage not recorded on PO | S3 financial control fails because default tolerance is £0 → S5 → finance investigates; automation cannot decide carriage is acceptable | **PASS — rejected from straight-through flow** | The circuit does not turn an unexplained £25 difference into an accounting assumption | | **4 — Silent duplicate that defeats naive checking** | Original invoice recorded as `000731`; resent invoice is keyed as `731`, has a different PDF filename and arrives in a new email | Invoice-number normalization makes both records equivalent; S3 duplicate control returns FAIL → S5 | **PASS — rejected** | A naive filename/message-ID/exact-string check could accept it. The supplier + normalized invoice-number key catches it | | **5 — Compromised legitimate supplier mailbox** | Attacker has access to a real supplier's established Outlook address, copies a valid open PO number and amount, and submits a convincing invoice with altered payment details | S1–S3 may all pass. S4 must visually compare payment instructions with previously approved supplier evidence. If the changed detail is noticed, S5 blocks it. If the forged invoice contains no observable change that distinguishes it from a legitimate invoice, the available systems cannot prove fraud | **FAIL against a sufficiently sophisticated forgery** | Outlook domain, PO and amount controls authenticate consistency, not the human intent of the supplier. Without a trusted supplier-verification or receipt/fulfilment source, this cannot be solved reliably by the named tools | Case 5 is intentional. Claiming that Zapier, Outlook and PO matching could reliably identify a compromised legitimate supplier account would create precisely the false confidence this design is meant to avoid. The control should therefore explicitly say: **A perfect PO match is evidence of accounting consistency, not evidence that the invoice is genuine.** --- # 9. First bottleneck Automate **S1 plus the duplicate screen surrounding S3 first**: Outlook intake → SharePoint preservation → control register → normalized duplicate detection. Do **not** begin with autonomous invoice matching or Xero creation. There are two reasons. First, this attacks the stated catastrophic risk at the earliest point. Every invoice gets a durable identity and every later attempt to introduce the same supplier invoice number encounters the same control register. It also eliminates the dangerous ambiguity between: * a genuinely new invoice, * a supplier resend, * an Outlook forwarding duplicate, * a Zapier retry, * and a Xero write whose response was lost. Second, it should recover a meaningful portion of the current 14 hours without requiring unreliable PDF interpretation. At 180 invoices/month, the current workload averages about **4.7 minutes per invoice**. If automated intake, filing, register creation and duplicate pre-screening remove even **90–120 seconds per invoice**, the saving is approximately: **180 × 1.5–2 minutes = 270–360 minutes = 4.5–6 hours/month.** That saving should be verified with a two-week before/after sample rather than accepted as a forecast. The remaining 8–9 hours are less attractive initially because they contain the judgement-heavy work: validating PO differences, recognising suspicious supplier behaviour and reviewing invoice/payment details. Automating those before acquiring trustworthy parsing and verification inputs would reduce visible labour while increasing hidden risk. Only after S1/duplicate control has operated without unexplained duplicates for a full accounting cycle would I add deterministic PO matching. Xero creation comes last, and even then only behind S4. --- The **biggest risk left** is a fraudulent invoice delivered through a legitimate supplier identity and constructed from genuine PO information. None of the listed systems provides an authoritative proof that the supplier actually issued that invoice. The earliest signal is therefore a **change in payment instructions, an invoice that operational staff were not expecting, or a supplier/source pattern inconsistent with prior approved invoices**. Those signals should stop the circuit at S4/S5 rather than be explained away by a successful PO match.