How to build an invoice approval queue

What matters here

• An invoice queue is four parts: intake, matching against what was already approved, an exception path, and a payment-ready state.
• Most invoices should never need a human. If everything lands in a queue for review, the queue is a re-approval process rather than an exception process.
• Three-way matching means invoice, purchase order and receipt of goods or service agree. Two-way skips the receipt, which is common for services and fine if you know that is the trade.
• Tolerance thresholds are what make auto-matching usable. An invoice that differs by rounding should clear; one that differs by 30% should not.
• Duplicate detection belongs at intake, not at payment. The same invoice arriving twice by two routes is the most common and most expensive error.
• The queue reads and writes to a finance system, so managed credentials and a named owner are not optional extras.

Who this is for

You run accounts payable or finance operations. You already know your approval matrix and your payment terms. What you want is for the invoices that match what was approved to clear without a human, and for the ones that do not to be obvious.

How it works in practice

What happens to an invoice from the moment it arrives to the moment it is paid.

1. 1

   It lands in one place

   However it arrived, emailed, portal or scan, it becomes one record with the supplier, number, amount and any purchase order reference.

2. 2

   Duplicates get caught at the door

   Same supplier and number, or same supplier, amount and a nearby date, gets flagged before anything else touches it.

3. 3

   Most invoices clear without a human

   If it matches the purchase order within tolerance, it clears and goes straight to the payment-ready list, with a record of what it matched.

4. 4

   The rest become exceptions with a reason

   No order, over tolerance, quantity mismatch, unknown supplier. Each routes to whoever can resolve that kind, not to a shared pile.

5. 5

   An approver sees the discrepancy, not two documents

   Invoice on one side, order on the other, difference highlighted. No opening attachments to find the gap.

6. 6

   Payment-ready, with the discount dates in view

   A clean list of what is approved to pay, sorted by due date, with early-payment windows flagged before they close.

1. 1

   Every invoice in one place, duplicates caught

   Intake, and the single most expensive error in accounts payable.

   Copy

   In this Helix project, build me an invoice approval queue.
   
   Start with intake. Every invoice becomes one record: supplier, invoice
   number, dates, currency, totals, line items, and the purchase order
   reference if there is one. Let me type one in and attach the original
   document.
   
   Before anything else touches a new invoice, check whether we have seen it
   before. Flag it if the supplier and invoice number already exist, and flag
   it if the supplier, total and date are all close to something we already
   have. Show me the suspected duplicate side by side rather than rejecting
   it. The same invoice arriving twice by two routes is the most common
   mistake in this whole process and it costs real money.
   
   I sign in through Helix, so do not build a login page. Read the signed-in
   user from the runtime. And do not put any key or connection string in the
   code: if this needs to reach another system, tell me and I will create the
   connection in my workspace.

   Worth knowing. Duplicate detection has to run first. Catching it at intake costs one prompt; catching it at payment costs a supplier conversation.

2. 2

   Matching, so most invoices never reach a person

   The part that decides whether this saves time or just moves the pile.

   Copy

   Now match invoices against what was actually approved.
   
   I will give you purchase orders with their line items. Match each invoice
   by reference, and fall back to supplier plus amount when the reference is
   missing, because it often is.
   
   Set tolerances in one place I can edit: an absolute amount and a
   percentage, whichever is smaller. Inside tolerance, the invoice clears on
   its own and goes to the payment-ready list. Outside it, or with no order
   at all, it becomes an exception with the reason attached.
   
   Every automatic clearance still writes down what it matched and why. "It
   cleared automatically" is a decision, and somebody will eventually ask
   what it matched against.

3. 3

   The exception queue

   The screen a person opens, and what has to be on it.

   Copy

   Build the queue itself, and only put exceptions in it.
   
   Each row shows what the invoice says, what the order said, and the
   difference between them, next to each other. An approver should never have
   to open two documents to find a discrepancy.
   
   Route each type of exception to whoever can resolve that type. Missing
   order, over tolerance, quantity mismatch, unknown supplier, suspected
   duplicate. A single shared pile means everything waits for whoever looks
   first.
   
   Actions: approve anyway with a reason, reject with a reason, send back to
   the supplier, or reassign. Sort by days to the payment due date, because
   paying late is the actual cost of a slow queue.

4. 4

   Ready to pay, and the record behind it

   The handoff, and the evidence.

   Copy

   Finish with the payment-ready list.
   
   Everything approved and not yet paid, grouped by supplier, sorted by due
   date, with early-payment discount windows flagged before they close. A
   queue that pays on time is table stakes. One that catches the discount
   pays for itself.
   
   Let me export a batch for the payment run and mark it paid so it leaves
   the list.
   
   And keep an appended record of every state change, with who, when, and
   what the invoice and the match looked like at that moment. Give me a
   supplier view too: every invoice from one supplier and its status, which
   is what I need open when they ring.

5. 5

   Connect it to real systems

   The step that turns a working prototype into something with your data in it.

   Copy

   Now connect it to the systems we actually run, so it works on real data
   rather than the rows you seeded.
   
   Anything in angle brackets is a placeholder. Swap it for whatever we use
   instead, and have the app name the connection it wants rather than assume
   a vendor, so changing my mind later is a config change and not a rewrite.
   
   <NetSuite>. Read purchase orders to match against, and push the approved
   payment batch back.
   
   <Gmail>. Pull invoices that arrive as attachments, so intake is not
   somebody retyping them.
   
   <Slack>. Tell an approver an exception is waiting, with the discrepancy in
   the message.
   
   <Google Drive>. Keep the original invoice attached to its record for the
   audit trail.
   
   <Coupa>. Read the purchase orders and receipts that three-way matching
   needs.
   
   <Snowflake>. Land cleared invoices next to the purchase orders, so spend
   by supplier and by cost centre is one join rather than two exports.
   
   <Brex>. Match card-paid invoices, which otherwise arrive twice and get
   paid twice.
   
   Only write where I have said to write. Everything else is read only.
   
   Do not write a key, a token or a connection string anywhere in the code,
   and do not ask me to paste one. Tell me which connections you need and I
   will create each as an authentication in my Helix workspace. Reference
   them by alias.

   Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.

6. 6

   Ship it

   The last step of every build: a URL, and the right people on it.

   Copy

   Deploy my app.

   Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. This app decides what money leaves the company, so set Access Control before sharing and scope it to the people whose approvals actually count.

What it connects to

An invoice queue is only as good as what it can see, and most of what it needs already lives somewhere else.

• NetSuite

  Read purchase orders to match against, and push the approved payment batch back.

• Gmail

  Pull invoices that arrive as attachments, so intake is not somebody retyping them.

• Slack

  Tell an approver an exception is waiting, with the discrepancy in the message.

• Google Drive

  Keep the original invoice attached to its record for the audit trail.

• Coupa

  Read the purchase orders and receipts that three-way matching needs.

• Snowflake

  Land cleared invoices next to the purchase orders, so spend by supplier and by cost centre is one join rather than two exports.

• Brex

  Match card-paid invoices, which otherwise arrive twice and get paid twice.

Each line says whether the app reads, writes or both. Anything not described as writing should be read only.

Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.

Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.

Related guides