Case study
BillOps: Cloud Invoices and FinOps Reporting, Automated End to End
- AI Adoption
- Google Cloud
- Automation
- FinOps
BillOps is an invoice-extraction and FinOps reporting pipeline that Aqvantiq designed and built for a regional SI partner. It reads cloud billing invoices, extracts the line detail, writes the result back into the spreadsheet format the client was already using, and flags anything it is not confident about for a person to check. It handles more than 300 invoices a month — and cloud invoices are not one-pagers: they run from around 20 pages to around 200, averaging about 50, so the pipeline reads more than 15,000 pages a month — at roughly 99.99% extraction accuracy — measured per invoice, before any human review touches it — removed over 95% of the processing time, and runs for about 20 US cents per invoice — well under one US cent per page. It is a bespoke engagement, not a product.
Two manual processes were consuming the same team
Two jobs were being done by hand, and underneath they were the same job.
The first was invoice processing. Staff opened each cloud billing invoice, read it, and keyed the figures into an Excel sheet — one invoice at a time, every billing cycle.
The second was the FinOps report. Someone downloaded the cost detail from the cloud billing console, did the transformation by hand, did the enrichment by hand, and consolidated the result through Excel pivot tables. Every month, from the top.
Neither job was hard. Both were slow, both were repetitive, and both placed a ceiling on how much anyone downstream could trust the numbers, because the accuracy of the whole reporting chain was the accuracy of the keying that fed it.
The build is Google Cloud end to end
The pipeline is written in Python and runs on Google Cloud, with Power BI as the one non-Google component on the reporting side. The services in the build are Cloud Storage buckets, Cloud Tasks, Pub/Sub, Gmail, Google Sheets, Google Drive, Apps Script, Secret Manager, Firestore, BigQuery, the Gemini API, Document AI and Cloud Run functions.
Two of those carry most of the extraction weight — Document AI and the Gemini API — and Firestore holds the extracted record. None of it is exotic, and that is deliberate: the client already had a Google Workspace and Google Cloud footprint, so the pipeline runs on services their own people can see, audit and eventually operate.
The interesting part of BillOps is not the extraction. For this document set — machine-generated cloud invoices in a known family of layouts — extraction was the solved half once the right two services were in front of it. The interesting part is what happens to the extractions the system is not sure about.
The review layer is the client’s own spreadsheet
The design decision that made BillOps stick was refusing to build a review application.
Extracted data maps back into the client’s existing Excel format. Not a format like theirs, not an export that approximates it — the one they already had, with the columns they already used. Every row of it is written by the pipeline.
Each row carries links into Google Drive for both the original document and the processed one, so a reviewer never has to go looking for the source. A validation column carries the state of that row, with four values: verified, pending review, system verified, and rejected.
Extractions that fall below the accuracy threshold are written as pending review automatically. The reviewer opens the Drive link on that row, checks the value against the source document, and corrects it in the sheet. The correction syncs straight back to Firestore, and the reviewer flips the row to verified.
That loop is the whole of the human-in-the-loop design, and three useful things fall out of it:
- There is no second tool to learn. The review surface is the artifact the finance team was already working in, so adoption cost nothing and no one had to be trained onto a queue.
- The audit trail is the deliverable. Every row shows its own state, its source document and its processed document, side by side. There is no separate log to reconcile against.
- Uncertainty has somewhere to go. A confidence threshold is only useful if the low-confidence cases land somewhere a human actually looks. Here they land in the sheet that person opens anyway, marked pending review.
The last point is the one worth taking away from this build. Plenty of extraction projects reach good accuracy and still fail, because the five percent the model is unsure about has nowhere to be resolved and quietly becomes everyone’s problem.
The numbers
| Measure | Result |
|---|---|
| Invoices processed | 300+ per month, from ~20 to ~200 pages each (about 50 on average) |
| Pages read | 15,000+ per month |
| Processing time | 95%+ reduction |
| Extraction accuracy | Approximately 99.99% of invoices extracted correctly, measured before human review |
| Running cost | About 20 US cents per invoice — well under one US cent per page |
One reconciliation, because our AI adoption page says we will not quote an accuracy figure before seeing your data: this number was measured, not promised. Whole invoices scored correct or not, on this workload’s own production volume, before the human review pass — a result from this document set, not a general guarantee. That is the difference between publishing a measurement and publishing a pitch.
The running cost deserves its own line. About 20 US cents per invoice — and with invoices averaging around 50 pages, well under one US cent per page read, extracted, validated and written back. That is a unit cost small enough to stop being a factor in the decision — which matters, because the FinOps report that BillOps produces exists to argue about costs. A reporting pipeline that is itself a meaningful line item is an awkward thing to defend.
This was scoped for one client’s process
BillOps is a bespoke and curated solution rather than a productized SaaS. The extraction is generic; the value is in the parts that are not — the client’s own spreadsheet format, their validation states, their thresholds, their Drive structure. A generic invoice product would have delivered the same extraction accuracy and none of the adoption.
The engagement was managed by Anson Lau, the founder, and delivered by the same group of engineers, with the engineer who scoped the extraction and review flow staying accountable for it through delivery and handover.
If you are looking at a manual process with this shape — high volume, low difficulty, a real accuracy requirement, and a human who has to stay in the loop for the cases that matter — that is the work described on AI adoption and generative AI consulting. The reporting half of the story, where cost detail becomes a FinOps report someone can act on, sits closer to managed cloud services.