Four places your team retypes data that already exists - the supplier's PDF, the cart, the agreed price, the accounting handoff - and the check each one needs.
Four times in a normal purchasing cycle, someone in your company retypes information that already exists in machine-readable form about eighteen inches away.
The supplier's document - a PDF generated by a computer, printed to a page, and typed back into a computer at your end. The webshop cart - a structured basket of items with quantities and prices, transcribed by hand. The price you already agreed - negotiated once, then looked up, remembered or guessed at on every subsequent order. And the handoff to accounting, where an approved order is keyed a second time into a different system.
None of the four creates new information. All four are the same failure: information that exists is not carried forward, so a person carries it.
One thing runs through all four. This is not an article about letting the computer do it. Automating an input is only safe if the system tells you where it was unsure. Every section below pairs the automation with its check, and the check is what makes it worth having.
One: the supplier's document
A supplier sends a PDF invoice with forty lines. Typing it carefully takes about fifteen minutes and produces small errors in proportion to how late in the day it is.
Foxpedite reads the PDF or scan and extracts header fields, line items and totals, using a Gemini vision model configured at platform level with a fallback. Extraction is the easy half; calibration is the product.
Every extracted field comes back with a confidence score from 0 to 100. Fields below the threshold are flagged individually, and any flagged field puts the whole document into review rather than ready. The extraction carries bounding boxes, so the reviewer sees each value against a highlighted region of the original page - checking a value means glancing at where it came from, not hunting for it.
The unit of doubt is the field, not the document. A system that grades its confidence in a whole invoice has told you nothing you can act on. One that names three shaky fields and shows where each came from has told you exactly what to do and how long it will take.
So the forty-line invoice reads: thirty-seven lines clear, three flagged - a wrapped description, a quantity printed over a gridline, a currency symbol inside a number cell. Under a minute to review. Fifteen to type, and nobody checks typing afterwards, because they just did it.
One safety rule: a captured document always posts as a draft invoice or draft purchase order. It never enters the approval workflow on its own, and a duplicate-reference check runs before it posts. Extraction proposes; a person commits.
The routes a document can arrive by: upload, scan, the API capture endpoint, supplier upload through the supplier portal, and the extension capturing an attachment off an open message. Worth stating because readers assume otherwise - you cannot forward an invoice to a Foxpedite address. That is not a route today. Document intelligence is Advanced. (Document intelligence → · Invoices → · Pricing →)
Two: the cart, and the emailed quote
A workshop manager fills a cart with eight items, screenshots it, emails it to the office, and someone there retypes it into a purchase order. Twenty minutes and two people, and the retyping is where the error enters.
Foxpedite Capture is a Manifest V3 Chrome extension with two surfaces - a toolbar popup and a side panel, the panel being the one that stays open while you work. It captures from a webshop cart, or from an open message in Gmail or Outlook, as either a purchase order or a quote. It authenticates with a scoped API key generated in Foxpedite's settings: an ordinary API client, no privileged back door. Regular plan. (Chrome extension →)
The cart, and the recipe it learns
Cart extraction runs three stages, cheapest and most reliable first. A learned recipe for that specific site, if one exists. Then schema.org product data the page already publishes about itself - structured, authoritative, free. Then, only when confidence falls below the threshold, a model call.
There are no per-retailer adapters and no list of supported shops. A shop publishing clean structured data works on the first visit; one publishing nothing gets the model, and then a recipe - because correcting a scrape before you submit it is how the extension derives a selector recipe for that site. Next time, stage one handles it and nothing else runs.
Recipes are stored locally per browser profile, never synced unless the company opts in, and retired automatically after repeated failures - with the retirement recorded, so a later sync cannot silently resurrect a recipe retired for being wrong. The learner returns nothing when a step is ambiguous, on the principle that no recipe is better than a wrong one: a missing recipe costs one model call, a confidently wrong one costs a purchase order that looks right.
Eight lines, forty seconds, one person.
The inbox, and four constraints
Capturing from email is the feature people are rightly suspicious of, so here is exactly what it does.
It reads one message - the one open on your screen. No mailbox API, no thread walk, no message-list enumeration. Not disabled: absent. There is no code in the extension that could do it.
The reader is injected only in response to an explicit capture click. The cart scanner, separately, injects nothing at all on a mail host, and there is a test named for keeping that true.
The mail hosts are optional permissions, requested the first time you capture a message, one exact host at a time - mail.google.com, outlook.office.com, outlook.office365.com, outlook.live.com. A Gmail user is never asked for Outlook; someone who only uses cart capture is never asked for anything. The install prompt stays quiet.
Attachment downloads run inside the message's own page, on your existing mail session's cookies, so the extension never sees, stores or needs a mail credential - and it fetches only the attachment you picked.
In practice: a supplier emails an eleven-line PDF quote. You open the message, capture it as a quote, and the attachment joins the same document queue as section one - extracted, three fields flagged, reviewed in under a minute, landing as a draft. To repeat: capture from a message you have open, not forwarding to a Foxpedite address.
The second-order effect is the interesting one. When raising a purchase order takes forty seconds, people raise purchase orders. Most off-process spending is friction, not defiance - and the cheapest way to bring spend back inside the process is to make the inside faster than the outside.
Three: the price you already agreed
Some prices should be looked up, some competed. Most teams have it backwards.
The approved catalog holds items with agreed prices, optionally per vendor, with quantity break points and validity windows. Prices are immutable: a new price supersedes the old rather than overwriting it, and overlapping windows are rejected, so "what was the agreed price in March?" always has an answer. A preferred vendor is advisory and never blocks. A PO line snapshots the catalog price it used, so the order does not change meaning when the price list moves. And an approval rule can branch on whether a line is off catalog, which turns "we have a catalog" from a convenience into a control. (Purchase orders → · Vendors →)
RFQ is the other half: draft the request, publish it, invited suppliers quote in their own portal, compare line by line in a side-by-side matrix, and award - which converts the winning quote straight into a draft purchase order rather than a retyping job.
The rule is short. Bought three times at a stable price? Catalog it and never quote it again. One-off, large, or a moving market? Quote it and never inherit an old price.
The inverted version is common, and worth checking whether it is yours: the cleaning concentrate gets three quotes every month because the process says so, while the annual order for 200 chairs goes to last year's supplier at last year's price because everyone was busy that week. Effort spent precisely where it cannot pay back, absent where it could.
Catalog is Regular, RFQ is Advanced. One limitation worth stating: catalog price comparisons are same-currency only - prices in other currencies are excluded rather than converted at a rate that would be wrong by the time anyone read it.
Four: the handoff to accounting
QuickBooks Online connects by OAuth, imports your chart of accounts, and pushes approved purchase orders. That is the scope. It does not sync vendors, push bills, move attachments, or listen for inbound changes. The edges of an integration are more useful to know than the logo.
Inside that scope sits a trap. A Foxpedite line total is VAT-inclusive. A QuickBooks line amount is net. Map one onto the other and every document is overstated by its tax - an error that reconciles perfectly inside the integration, because both ends agree, and is wrong everywhere else. The general form: two fields with the same name in two systems are not the same field.
Which is why the integration refuses things. Launch is US-only, and a reverse-charged, non-US or foreign-currency document is refused with a specific message rather than filed as zero-rated - because those are different things on a return.
Picture a €4,800 reverse-charged order going through a system that approximates instead. It posts. It reconciles. It looks fine until March, when an accountant finds it, and now there is a correction, an explanation, and a question about what else is wrong. Against that: a refusal today that inconveniences one person once and tells them exactly why.
Teams who would rather build the handoff themselves have a REST API with scoped keys and signed outbound webhooks - order created, approved, rejected; invoice received and matched; delivery posted; budget threshold reached; flags raised. (API documentation →)
QuickBooks Online, the API and webhooks are Advanced. The integration layer is built provider-agnostic, so other accounting systems can follow. We are not going to tell you which ones or when.
The check is the point
Read back through the four. Flagged fields. A review queue a document cannot skip. The draft-only rule. The off-catalog condition. A push that refuses rather than approximates.
Every automation here is paired with a place where the system declares its own uncertainty. That pairing is why the automation is safe to rely on. A system that is never unsure is not more accurate - it is quieter about being wrong.
If you want to try it: 14-day free trial, no credit card. $30 per seat on Regular - purchase orders, three-way match, catalog, budgets, multi-currency and VAT, the Chrome extension - minimum five users. $35 on Advanced, which adds approval workflows, RFQ, inventory, workforce, QuickBooks Online, the API and webhooks, document intelligence and vendor scorecards. (Pricing →)
The rest of this series: where the money leaks in spreadsheet purchasing, approval workflows that don't end at the owner's desk, and three-way match explained.
The documents, carts and orders described here are worked illustrations written for this piece, not customer data.