Skills / Document extraction and conversion

Invoice Extraction and GL Coding

Eighty percent of a vendor invoice batch codes itself the moment it lands: the same vendor, the same account, month after month. The other twenty percent, a brand-new vendor, an account the chart of accounts quietly deactivated, a vendor whose coding has genuinely shifted, is where an AP coder's actual day goes. This skill is built around that split: propose the predictable majority straight from the vendor's own coding history, stated as a real, checkable statistic rather than a model's opinion, and put everything else in an exception queue instead of coding it anyway.

What it does

Starting from an invoice extract (vendor, amount, date, and line description, already pulled from the PDF or inbox by whatever extraction step runs upstream), the chart of accounts, and a frequency table of how often each vendor has historically been coded to each account, this skill proposes a GL code for every invoice it can code safely. Confidence is the share of that vendor's historical invoice count that went to the proposed account, shown with its basis, not a black-box score. Everything landing below a stated confidence floor, along with every invoice from a vendor with no coding history or a proposed account that's missing or inactive, goes to a separate exception queue instead.

The one rule it can't skip

It never performs the extraction itself. This skill assumes invoice text is already in structured rows; it does not parse a PDF, an image, or an inbox, and it never finalizes a code on its own authority either. A proposed code is a statistic-backed proposal with its basis shown, for an AP coder or Controller to confirm, correct, or reject; the chart of accounts and the vendor's own coding history set the ceiling on what can be proposed, never a general sense of what an account "should" be.

How the coding proposal actually runs

For each invoice, the skill counts how that vendor's prior invoices have been coded and proposes whichever account carries the largest share of that history, with confidence equal to that share exactly, not weighted by how similar a line description or amount looks. A vendor coded to one account on every invoice in its history produces 100% confidence; a vendor split across two accounts produces a lower, honestly stated confidence on the majority account. Every proposal's basis, the exact count behind it, rides along on the register, so a reviewer can check the math without re-deriving it. A vendor with no history, or a proposed account missing or inactive in the chart of accounts, is never coded; it's routed to the exception queue instead, and an invoice always lands in exactly one of coded-with-confidence or exception, a reconciliation check the workbook itself enforces.

What it won't do

It won't code anything from a line description or an amount pattern alone; the only basis for a proposal is a vendor's own historical coding frequency against an active chart-of-accounts code. It won't guess at a vendor whose coding has recently and materially shifted; it reports the historical pattern and lets a reviewer judge whether the shift is intentional. It won't treat a duplicate invoice_id as two separate invoices; a repeated ID makes the population ambiguous and is rejected outright rather than coded twice. And it won't post anything to the ledger or an ERP; the coded register and exception queue are handed off for whatever approval and posting process AP already runs.

Inputs and output

InputsAn invoice extract (vendor, amount, invoice date, line description), the chart of accounts with an active/inactive flag, and historical coding frequency by vendor and account
OutputA coded invoice register with a confidence score and basis per line, and a separate exception queue for new vendors, inactive accounts, below-floor confidence, and parse failures
Who it's forAP staff and the staff accountants who code the invoice backlog every cycle, and whoever reviews and releases coding before it reaches the ERP

Adopt's agents propose the code your own vendor history already supports, show the exact count behind every proposal, and hand anything new, inactive, or uncertain to a reviewer instead of guessing. Nothing posts to your books until someone approves it. Sign up free, or book a pilot to run it against a month of your own invoice backlog.