Automating invoice capture into IFS Cloud, end to end

Why invoice entry is still manual

Most invoices arrive as PDF attachments in a shared mailbox, and every supplier formats them differently. Traditional capture tools tried to tame this with per-supplier OCR templates — which work on day one and decay from day two, as suppliers redesign layouts, add lines, or switch languages. The template backlog grows, trust drops, and the AP team quietly goes back to keying invoices into IFS by hand.

The cost is not only the typing. Manual entry means late registration, which means missed early-payment discounts, blind spots in cash forecasting, and a month-end crunch where accruals are guesses. The fix is not a better template engine — it is removing templates from the architecture entirely.

The target architecture

Six stages, each one observable and each one allowed to fail safely:

1. Capture — a trigger fires when an email lands in the AP mailbox.
2. Extraction — an AI agent reads the attachment and produces structured invoice data.
3. Validation — the flow checks supplier, purchase order and duplicates against live IFS records.
4. Posting — a clean match is registered in IFS Cloud through the native connector.
5. Exceptions — anything unclear routes to a human approval inside the flow.
6. Notification — outcomes land in Teams, where the AP team already works.

In NgageFlow's visual builder this is one flow with a branch: clean invoices take the straight path, exceptions take the human path, and both paths end in IFS and Teams. There are also ready-made templates that start from this exact shape.

Step 1 — capture: the email trigger

Start with a dedicated mailbox — ap@yourcompany.com — connected through a one-click OAuth connection, so the AP lead can authorize it without IT tickets or shared passwords. The flow triggers on each new email, filters for invoice-like attachments, and records the message ID so the same email can never produce two invoices, even if it is forwarded twice.

Resist the temptation to filter senders aggressively at this stage. Let everything invoice-shaped into the flow and let validation sort it out — a rejected email with a reason is auditable; a silently dropped one is a phone call from an unpaid supplier.

Step 2 — extraction: an agent reads the invoice

An AI agent step opens the attachment and extracts what a clerk would: supplier name and tax ID, invoice number and dates, currency, line items with quantities and prices, tax amounts, and totals. Because the agent reads the document rather than matching a template, a brand-new supplier costs nothing extra, and a redesigned layout is a non-event.

Two practices make extraction production-grade. First, normalize at the boundary: dates to ISO format, decimal separators unified, currency as a code rather than a symbol. Second, make the agent state its confidence per field — a low-confidence total should route to a person even if everything else looks fine. The goal is not extraction that is always right; it is extraction that knows when it might be wrong.

Step 3 — validation against IFS records

Extraction gives you what the supplier claims; validation checks it against what IFS knows. The flow queries IFS Cloud projections directly — live records, not a nightly copy:

• Supplier exists: look up the supplier entity set by tax ID. No match means an exception, not a guess.
• Purchase order match: pull the supplier's open purchase orders and compare invoice lines to PO lines — prices and quantities within the tolerances finance agreed to.
• Consistency: invoice currency matches the PO currency; totals add up from the lines.
• No duplicates: check existing purchase invoices for the same supplier and invoice number before anything is created.

This is where a native connector earns its keep: the checks are queries against typed entity sets, not hand-built HTTP calls with hand-rolled authentication. The IFS Cloud connector also introspects entity schemas, so the flow knows which fields are mandatory before it ever attempts a create.

Step 4 — posting via IFS actions

A clean match becomes an IFS record. The flow creates the supplier invoice through the connector, referencing the matched purchase order, with safe concurrency — if the underlying record changed while the flow was running, the write fails cleanly instead of overwriting someone's parallel work. Where your process requires it, the flow then executes the relevant IFS action, so IFS's own business logic, posting rules and authorization routes run exactly as they would for a manually entered invoice.

Keep the evidence chain: store a reference from the IFS record back to the source email and PDF, so an auditor can walk from any posted invoice to the original document in seconds.

Step 5 — exceptions and human approval

Exceptions are not failures; they are the product. Define the classes up front — unknown supplier, no matching PO, tolerance breach, suspected duplicate, low-confidence extraction — and give each one an owner. When the flow hits one, it pauses on a human-in-the-loop approval step: the approver sees the extracted invoice and the relevant IFS records side by side, plus a one-line reason like "line 3 unit price exceeds PO tolerance." They approve, correct or reject, and the flow resumes from exactly where it paused.

The discipline that matters: nothing posts without either a clean match or an explicit human decision, and every decision is logged. That sentence tends to end the audit conversation.

Step 6 — closing the loop in Teams

The flow's last step tells the team what happened, where they already work. A Teams message per exception with a link to the approval task; a daily summary to the AP channel — invoices posted, exceptions waiting, oldest exception age. Visibility is what makes the automation trusted: nobody wonders what the robot did today, because the channel says so. More patterns like this live in the ERP notifications use case.

Implementation checklist

Before the first invoice flows, have these ten things in place: