Invoice processing is one of the tasks people most expect to automate, and one where the claims are most often overstated. Here is the work a build actually takes over, step by step, and the part that stays with a person no matter how good the extraction gets.
An invoice arrives, usually as a PDF attached to an email or dropped in a shared folder. Somebody opens it, reads the supplier, the invoice number, the date, the line items and the total, and types those into the accounting system. Then they file the original somewhere it can be found again. A build does the same four steps: it watches the inbox or folder, extracts the fields, writes them into the accounting system through its API, and files the original with a link back to the record it created. Nothing about that sequence is clever. It is the same work, done by something that does not get bored on the fortieth invoice.
Field extraction from a clean, machine-generated PDF is reliable enough to run unattended, and most supplier invoices are exactly that. It gets worse fast in three cases: scans of paper, especially faxed or photocopied ones; handwritten annotations, which is common where somebody writes a job number on the invoice before passing it on; and layouts that change without warning, which happens whenever a supplier switches their own billing software. A build handles the first case by routing low-confidence extractions to a person instead of guessing, which is a design decision, not a limitation to be engineered away.
Three things. Approval, because deciding a charge is legitimate is a judgement about your business that nobody should hand to software. Coding to the right account or job, where the invoice itself does not say and somebody has to know. And genuine disputes, where the amount is wrong or the goods never arrived. A well-built automation makes these three arrive as a short queue of exceptions with the extracted data already attached, rather than removing them. That is the difference between a build that survives and one that gets switched off after a month.
The calculator uses 60 to 85 percent for document and invoice processing. The low end is a business with a lot of paper, mixed suppliers and a real approval chain. The high end is one where invoices arrive as clean PDFs from a stable set of suppliers and coding is predictable. That is a CloudBuilder AI scoping assumption rather than a published figure, and where a specific business lands inside it is what an audit is for. If your invoices are photographed on a phone and emailed in, expect the low end or below.
Two things decide most of it. Whether your accounting system has a documented API you are actually licensed to use, which is often a plan-level question rather than a product-level one. And how many invoices you genuinely process a month, counted rather than estimated, because the difference between forty and four hundred changes whether a build pays for itself. The calculator will put a range on the second one; the first is a five-minute check with your accounting provider.