Invoice and PO intake automation with human approval

The inbox is still being keyed

Supplier invoices do not share a layout. They arrive as PDFs, scans, portal exports and email attachments, and the next supplier will use a template you have not seen yet. Someone in accounts payable still opens each one, finds the purchase order, and keys the lines.

A chatbot beside that inbox does not do this job. It can talk about an invoice. It cannot match one to a purchase order, and it should not be the thing that posts to your ledger. This is the work itself: read, match, post — or stop.

What breaks today

The failure is rarely a missing system of record. The usual picture is a purchase-order process that already exists, and a shared inbox that is the real front door. What breaks is the stretch in between.

• Layouts keep changing. The person who knows where a supplier hides the total is the process. When they are out, the queue is the process. If that work lives with one person, name it before you automate it.
• The match is the work. A missing PO number, a price that does not agree with the order, a partial delivery, a credit note that looks like an invoice. Keying the header is the easy part.
• Guessing creates a worse queue. A tool that posts the ambiguous ones does not return the hour. It moves the hour into cleanup, and the cleanup is harder to explain.
• The question arrives later. Which document, which values, who said it was safe to post. "It was in the inbox" is not an audit trail.

How Kultiv runs invoice and PO intake

This is a managed process, not a seat on a platform and not a chat window on accounts payable. It does the same four things a careful clerk does, and it refuses the step a careful clerk would refuse.

1. Read. The invoice is read as a document — supplier, header, lines, tax, the purchase-order reference — across the layouts you actually receive. The source file stays with the case.
2. Match. Those values are compared with the purchase order: supplier, quantities, prices, and what has already been received. A match is a comparison against your order, not a confident-sounding summary.
3. Post when it is clear. When the match clears the bar you set, the invoice is posted. Nobody is asked to re-key a document the process has already resolved. That is the straight-through path.
4. Hold the rest for a person. A missing purchase order, a price that does not match, a layout the process has not earned the right to trust, or a confidence that does not clear the bar goes to an exception queue, with the reason it stopped. A person approves, corrects, or sends it back. Nothing is guessed into the ledger.

You decide which cases always need a person, even when the match looks clean. Consequential postings keep that approval step. A human in the loop is the design, not a line under a demo.

The work runs in your environment, on the platform you choose. Your documents stay under your retention, residency and access rules. We use enterprise model endpoints that carry no-training commitments, and we will show you which services touch those documents before anything goes live. That is the same position as the data question on the homepage.

Why the audit trail matters

Finance does not get to answer "why did it post?" with "the model thought so."

Every decision keeps four things together: the source document, the values extracted from it, the confidence, and who approved it. That includes the invoices a person held back. A refusal is part of the record, not a gap in it.

The trail is what makes a wrong posting fixable. You can find it, explain it, and correct it. The monthly review says where accuracy slipped — in hours returned and straight-through rate, not in a count of tickets that only proves the queue was touched. We would rather return the hour than hand you a score you cannot defend.

The first six weeks

The engagement is the same one we run for any process, described on the homepage. It is not a platform rollout, and it is not priced per seat.

1. Week 0 — discovery call, free. About forty minutes. Bring the inbox and someone who actually keys the invoices. You should leave knowing whether the next step is worth your time, including if the answer is no.
2. Weeks 1–2 — map and measure. With the people who do the work. Live invoices, including the ones that do not match cleanly. Hours and rework, counted.
3. End of week 2 — a costed case. Where a build would return hours, and where it would not. You keep the findings either way. That fortnight is the fixed-fee discovery.
4. Weeks 3–6 — build the first slice. Scope agreed in writing before it starts. It runs alongside the people who do the work, so you can see what it would have decided before it posts anything.
5. Week 6 — live, still shadowing. Posting waits until you have watched it on your own invoices.
6. From the next month — managed operations. We stay on it. The exception queue, a supplier who changes a layout, and a written review. Measured in hours returned and straight-through rate — the share of invoices that post without someone re-keying them — not in tickets closed.

We will not put a price on a process we have not watched. Discovery is a fixed fee agreed up front; the build is quoted once the process has been measured; the ongoing fee is monthly, per live process.

Who this is for

Finance, accounts payable, and the operations lead who owns the inbox.

You already raise purchase orders. Invoices still arrive in layouts you do not control, and a person still turns them into postings. Keying is the job, and a wrong post has to be explainable months later — the usual constraint anywhere you cannot paste supplier documents into a public chatbot.

It is a poor fit when every invoice is a negotiation, or when there is no purchase order to match against. We would rather say that on the discovery call than stretch the word "match" until it means nothing.

Questions worth asking first

Related

If the offer in front of you is a document API, and the queue after it is still yours, read who owns the correction desk after a DIY document API.