Who owns the correction desk after a DIY document API?

The launch stops at the fields

A self-serve document API is an easy demo. You send a PDF. You get JSON: a supplier, a date, a total, a confidence score. For a team that is tired of re-keying, that looks like the process.

It is the first half. Documents do not share a layout, and extraction on the ones you actually receive is often only middling. The fields the model is unsure about, and the ones you cannot afford to get wrong, still need a person. That person sits at a correction desk. The launch rarely shows the desk. The contract rarely owns it.

What the API leaves behind

Reading a document is useful. The failure is the boundary the product draws, and the second system you discover after go-live. Intelligent document processing sold as an API stops at the response. Everything past that line is your project.

• Accuracy that is only middling. A clean sample is not your inbox. Scans, a new supplier, a total that lives in the footer, a document that is almost the type the demo was shown. The API still returns a value. A value is not a decision.
• A correction desk you staff or build. Someone has to see the low-confidence fields, change them, and know who changed them. If that desk was not part of the purchase, it becomes an internal project: a queue, a screen, and rules for who may overwrite a field.
• Drift with no owner. A layout changes. Extraction that was fine last month starts returning the wrong line. The API does not page anyone. Your team finds it when a person notices, which is late. If that knowledge lives with one person, name it before you automate it.
• An outcome you still have to defend. When a number is wrong in the system of record, "the API said so" is not a trail. You need the source document, the values, the confidence, and who approved it.

Owning the process

Kultiv is a Managed Intelligence Provider. We take the process — the exceptions, the human review, the audit trail — rather than handing you an endpoint and the queue that follows it. That is the same sequence as what we do, in this order. They are not modules you switch on.

1. Process intelligence. Before anything is built, we watch the work with the people who do it. Live documents, including the ones that do not extract cleanly. Hours and rework, counted. The exceptions nobody wrote down.
2. AI applied to the work. Models read and extract inside the process. Not a chat window next to the inbox, and not a raw API your team is left to finish.
3. Information architecture. Extracted values land in a governed place you already run, under your permissions. A spreadsheet that has become the real system of record is a finding, not a destination.
4. Managed operations. We stay. The exception queue, a layout that changed, and a written review of where accuracy slipped.

Human review sits on the cases that need it. Low-confidence fields go to an exception queue, with the reason the process stopped. Consequential decisions keep a person you name, even when the extraction looks clean. The process refuses to guess: a field that does not clear the bar is not written through. A person approves, corrects, or sends it back. A human in the loop is the design, not a line under a demo.

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

The work runs in your environment, on the platform you choose. We use enterprise model endpoints that carry no-training commitments, so your documents are not used to train a model. They stay under your retention, residency and access rules. 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.

What an API owns, and what we own

The useful question is not which model extracted the field. It is who is still responsible after the response comes back.

• Layouts. An API answers for the file you sent today. When a supplier changes a template, the correction desk is where your team meets it. A layout change is part of the process we run.
• Drift. An API does not come back next month and tell you extraction has slipped on your documents. The monthly review does — where it got things wrong, in hours returned, not in a count of tickets that only proves the queue was touched.
• Exceptions. The API's job ends at the response. Low-confidence and consequential cases are the correction desk. That desk is part of managed operations, not a second product you stand up after the integration.
• Outcomes. An API is accountable for a payload. We are accountable for the process: what went through, what was held, and whether the hour came back. Priced per process, not per call and not per seat.

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. Invoice and PO intake is one process with this shape: read the document, settle the clear cases, and hold the rest.

1. Week 0 — discovery call, free. About forty minutes. Bring the documents and someone who actually corrects them. 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 documents, including the ones that do not extract 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 writes anything.
5. Week 6 — live, still shadowing. Writing through waits until you have watched it on your own documents.
6. From the next month — managed operations. We stay on it. The exception queue, a layout that changes, and a written review. Measured in hours returned, 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

IT and operations, when the proposal on the table is a self-serve document API — or an intelligent document processing product you are expected to embed and then finish yourselves.

You have volume. The documents do not share a layout. A person still checks them, and a wrong value has to be explainable months later. That is the usual constraint anywhere you cannot paste those documents into a public chatbot.

It is a poor fit when you want an endpoint in a sprint and you are content to own the queue, the drift, and the audit questions. We would rather say that on the discovery call than stretch the word "managed" until it means a webhook.

Questions worth asking first

Related

Invoice and PO intake is the same bargain on a named process: match the clear invoices, and hold the rest for a person, with the document still attached.