A reparse is not a reversal
When a purchase order or supplier invoice posts with the wrong total, the instinct is to open the extraction, correct the field, and save. That updates your document record. It does not tell the ERP, the AP ledger, or the inventory feed that yesterday's post was wrong. On Deerman's manufacturer PO path and BuilderHelp's supplier-invoice OCR, a post that left the building needs a reversal lifecycle — not a quieter reparse.
Two systems, two verbs
Extraction and posting are not the same job. Extraction turns a PDF into structured fields. Posting commits those fields into something authoritative — an order in the ERP, an AP voucher, a goods receipt match. Once posting succeeds, the downstream system owns a document with its own identity, period, and audit trail.
A reparse rewrites the candidate you keep in the OCR app. A reversal creates an offsetting document in the system that already accepted the bad one. Confusing those verbs is how teams "fix" an amount in the review screen and still pay the wrong total, because the ledger never saw the change.
The practical rule is simple: if the post already happened, editing fields is preparation for a new post, not a substitute for undoing the old one.
Deerman: the manufacturer already shipped on the number
On Deerman, a purchase order that auto-posts with a transposed quantity does not stay a private mistake. The manufacturer may already be cutting against that number. Overwriting the extraction and hoping the next sync "updates" the remote PO is wishful coupling — most ERP and vendor portals treat a posted PO as immutable without an explicit change or cancel order.
What we ship instead is a disposition on the operational record: void or cancel the posted document with a reason, keep the original extraction and the posted payload as evidence, then post a new document from the corrected parse. The manufacturer sees a cancel and a replacement, not a silent rewrite of history.
Partials make this sharper. If three of five lines were right, the void still covers the whole posted document unless the downstream API supports line-level change orders. Pretending a field edit fixed the two wrong lines while the remote PO still holds the old quantities is how warehouses receive against fiction.
BuilderHelp: AP does not forgive quiet edits
BuilderHelp's supplier-invoice path posts into AP. A wrong GL account or tax total that has already posted cannot be cured by correcting the OCR fields alone. Accounting periods, clearings, and approvals sit on the posted voucher. The correction path is the one the ledger already understands: reverse (or counter-entry when reverse is blocked), then enter the corrected invoice.
We keep three artifacts when that happens: the original extraction, the posting receipt (external id, timestamp, period), and the reversal receipt. The corrected extraction becomes the source of a new post, not an in-place mutation of the first. That is slower than a save button. It is also the only shape that survives an audit question six weeks later.
If payment or clearing already touched the bad voucher, the UI has to say so. Offering "save corrections" when the period is closed or the item is cleared trains people to believe the app fixed money it does not control.
What the product has to expose
The review screen needs verbs that match reality: Correct fields (still local), Void / reverse post (talks to downstream), Post again (creates a new external document). Collapsing those into one "Update" action is the bug.
State on the document should make the seam visible: extracted, posted, voided, reposted — with foreign keys to every external id. Operators should see whether a field edit is draft-only or whether a reversal is required before anything else can leave the building.
Idempotency matters on both sides. A void retried after a network blip must not create two reversals, and a repost must not recreate the original voucher because someone clicked twice. Durable keys for void and for the replacement post belong in the same design as the happy-path post key.
What we ask before we wire auto-post
Before any confidence threshold or auto-post toggle ships, we ask what undoes a wrong post in the target system — reverse, cancel, change order, or counter-entry — and whether that path is available through the API we actually call.
We ask who is allowed to void, what reason codes are required, and what happens when the period is closed or the document is already cleared. If the honest answer is "we'll just edit the extraction," auto-post is not ready.
Reparse stays valuable. It is how you prepare the next post and how corrections become training data. It is not how you unwind a commit that already landed somewhere else.
Questions
- Why isn't editing the extraction enough after a wrong auto-post?
- The extraction lives in your OCR app. The posted document lives in the ERP or AP system with its own id, period, and audit trail. Changing local fields does not create the offsetting entry downstream unless you call a void/reverse (or equivalent) and then post again.
- When is a reparse the right move?
- Before anything posts, or after a void when you need a corrected payload for the replacement document. Reparse prepares the next commit and captures operator corrections — it does not substitute for reversal once a foreign system has accepted the bad post.
- What should the UI show operators?
- Separate actions for correcting fields, voiding/reversing the external post, and posting again, plus visible state (extracted, posted, voided, reposted) with external ids. A single Update button that silently mutates both sides is how quiet ledger drift starts.
Sources
- SAP — Reversal, counter entry, or document change — Why posted financial documents need an explicit reverse path rather than an in-place edit.
- Validating AI-extracted data before ERP posting — Separation of extraction, validation, and posting — and why audit trails matter after the fact.
- Invoice processing automation: OCR to ERP — OCR as preparation; business posting and corrections as a separate workflow.