Case study · Invoice automation
300 invoices posted into the ERP in 2 h 42 min.
A system migration left three months of outgoing invoices to post in the ERP. Our robots posted the batch through the same screens the team uses, and checked every invoice against its total.
- Client
- A Brazilian industrial construction groupPrecast concrete and construction · Name withheld
- Period
- May to June 2026
- Status
- DeliveredOne-time migration batch
- Result
- 2 h 42 minfor 300 invoices, about 32 seconds eachMeasuredExecution logs · May 8, 2026
Three months of invoices, screen by screen.
A system migration left a backlog of outgoing invoices issued from January to March 2026. All of them still had to be posted in the client's ERP, a web-based construction system.
Each invoice needs a receivable, a tax header and its line items, and each of those sits on a separate screen. The main batch alone had 300 invoices.
Robots that post each invoice and check the total.
We built robots in Python and Playwright. Instead of storing a password, they attach to the browser the team had already logged into, through the Chrome DevTools Protocol (CDP).
They read the batch from a spreadsheet and post every invoice, screen by screen. At the end of each one, they compare the sum of the items with the invoice total and write a log entry.
Four steps, invoice after invoice.
The same flow for every invoice in the batch, from the spreadsheet to the log.
- 01
Read the batch
The robot loads the invoices from a spreadsheet.
- 02
Post the invoice
It creates the receivable, fills in the tax header and adds the line items, screen by screen.
- 03
Check the total
It compares the sum of the items with the invoice total.
- 04
Log the result
Every invoice gets a log entry. That log is the source of the measured numbers below.
Stack
- Python
- Playwright
- Chrome DevTools Protocol (CDP)
- pandas + openpyxl
- Per-invoice log
Measured in the logs, invoice by invoice.
Measured numbers come from the robots' execution logs. The manual time is a team estimate and is labeled as one.
From the execution logs
≈32 s
per invoice, in a batch of 300 posted in 2 h 42 min
MeasuredExecution logs · May 8, 2026
295 of 300
invoices (98.3%) completed on the first pass; the other 5 on the next business day
MeasuredExecution logs · May 2026
305 of 305
invoices posted by the final flow, each total checked against its line items: zero discrepancies
MeasuredExecution logs · May 2026
281
more invoices for returned goods, May 13 to June 23, 2026; in one batch, 167 of 169 posted in 1 h 42 min
MeasuredExecution logs · May to June 2026
Robots against manual entry
2 h 42 min
for the robots to post the 300 invoices
MeasuredExecution logs · May 8, 2026
≈25 h
for the same 300 invoices by hand, at 5 min each
Team estimateNot timed
A one-time batch, with some rework along the way.
Limits
It was a one-time migration batch, not an ongoing routine. Five of the 300 invoices did not complete on the first pass; they were finished on the next business day.
Nobody timed the manual work. The ≈25 h figure is the team's estimate, at 5 minutes per invoice.
What we learned
Earlier versions caused rework. The batch ran on the final flow, which merged the steps into one.
A bulk-delete tool undid the test entries. Being able to undo in bulk mattered as much as posting in bulk.
Other projects we built.
21 of 22
weeks with the report delivered, June to October 2026
MeasuredExecution logs · June to October 2026Read the case studySince May 29, 2026 · Scheduled reports
A weekly report of contracts about to expire
Every Monday, a robot runs on its own: it signs in to the ERP, finds the supplier contracts ending within 15 days and emails the report.
156-274 s
per contract with 2 to 6 items, in validation
MeasuredValidation logs · July 9 to 14, 2026Read the case studyJuly 2026 onward · ERP integration
A contract robot, and an orchestrator so robots can share one login
A robot posts each new contract from the client's internal platform into the ERP. An orchestrator gives the shared ERP login to one robot at a time.
35
redirect rules that send each old sports-portal address to its new page
MeasuredServer configuration · October 31, 2026Read the case studySince May 2026 · Club management
One platform for a club's members, sports and management
A club website with a member area on the club system's API, a chat, sports competitions, dashboards and a tournament site, built from May to October 2026. The old sports portal moved into the new website with page-by-page redirects, and its links kept working.
8
modules live, from sales to financial BI
MeasuredClient portal · October 31, 2026Read the case studySince June 2026 · Manufacturing operations
An eight-module operations suite for a food manufacturer
Sales, accounting, finance, production, maintenance, fleet, HR and financial BI modules, built from June to October 2026. Each module has its own database, and payables are read from the ERP the company already uses.
30 days
of nightly backups kept, each one verified automatically after it runs
MeasuredServer configuration · October 31, 2026Read the case studySince October 4, 2026 · Financial control
Financial control for a notary office, where nothing is deleted
Every payable and receivable goes in as a provision, an entry made before it is due, and is then settled in full or in part. Corrections and cancellations are logged with a reason, every change records who made it and when, and the database is backed up and verified every night.
Free 30-minute automation assessment
Find the three repetitive tasksthat cost you the most.
In 30 minutes we map the three most expensive repetitive tasks in your operation and tell you what automating them would cost.