Automate instead of rebuild: an invoicing run as a real-world case

An IT services firm, and a process every service provider knows: at the end of the month, jobs performed turn into invoices. The technicians enter their appointments in the Outlook calendar, the billing runs off a list, and the invoices are created in the invoicing system. Everything works, only by hand: go through the appointments, match them to customers, transfer the line items, create the invoice. Roughly two person-days, every month, for years. The case is real and anonymised; we have just put the first half of the solution into production, and it is running.

The most expensive sentence in the industry

Anyone who takes a process like this to a software sales team hears almost always the same sentence: for that you need a new system. An ERP with a service module, an industry-specific solution, a workflow tool. The sentence is so expensive because it conceals two things. First, the true price: the licence is the smallest item, and behind it sit migration, training, data transfer, parallel running, and the months in which two systems are maintained side by side. Second, the risk: a working process is replaced by an unknown one, and the team has to change how it works. That is exactly where such projects fail most often, not on the software.

The honest counter-question is: what is actually broken? In this case: nothing. The calendar, the list and the invoicing system all do their job. The only thing broken is the connection between them, and that connection consists of people transferring data from A to B. That is not a systems problem. It is a bridge problem.

The brownfield route: connect instead of replace

The solution we built is deliberately unspectacular: a thin automation layer that connects the existing tools. The workflow stays exactly as the team knows it:

• The technician flags an appointment in the Outlook calendar as billable using a category, just as before. That is the only action, and it existed already.
• The tool reads the calendars every hour, calculates the time worked from the appointment duration, and matches the customer via the subject line.
• The jobs land automatically in the existing billing list, grouped by customer, with date, activity and units.
• At the end of the month, this produces a draft invoice per customer in the invoicing system. Prices and hourly rates stay where they always were: in the invoicing system itself.

That last point is a matter of principle I recommend to everyone: the automation duplicates no business logic. It only selects and transfers quantity and text. If prices suddenly lived in two places, the automation would have brought a second source of truth into the building, and two sources of truth are the start of every billing error.

The best automation is the one where the team does not have to change how it works. The billable appointment in the calendar was always there. Now it does the work too.

Control is not an add-on; it is the core

I build tools like this with an auditor's eye, and that eye asks three questions before every line of code: who decides? What happens when things go wrong? And can you prove afterwards what happened? The answers sit in four building blocks that turn a script into a tool fit for operational use:

• Human sign-off: there is no automatic invoice dispatch. The tool produces drafts and a preview; a person reviews and approves. Automation speeds up the preparation, not the responsibility.
• Idempotency: every processed appointment is re-flagged. What has been billed cannot accidentally be billed a second time, even if the run starts twice.
• A review list instead of data loss: appointments that cannot be safely matched to a customer do not disappear and are not guessed at. They are collected on a review list that a person works through.
• Audit log and reconciliation: every run writes a continuous, tamper-evident record, and the totals from the list and the invoice are checked against each other. That is auditability in practice, not on paper.

These four points cost perhaps a quarter of the build time. They are the difference between a tool that management can entrust its invoicing to, and a hobby project that grinds to a halt at the first edge case.

The invisible details where it really fails

The hype tells you that automations like this are clicked together in an afternoon. The truth sits in details that never show up in a demo. Three examples from this very project:

• Time zones: the calendar interface returns times that are technically correct, but with no time-zone marker. The list interpreted them as local time, and an 11:30 job silently became a 09:30 entry. Found in the reconciliation, fixed with explicit normalisation. Without a test, that would have been invoiced wrong for months.
• Name matching: customers are never named as cleanly in the calendar subject line as in the master list. Abbreviations, additions, contract references. The matching needs word boundaries and alias lists, otherwise it assigns the wrong customer, and a misassigned job is worse than an unassigned one.
• Fault tolerance: if one of several mailboxes cannot be read, the whole run must not die. The error is logged, the remaining calendars keep running, and the missing one is caught up later.

None of this is rocket science. But all of it decides whether the tool works on the ugly Tuesday morning when the data is messy. Anyone who sells you an automation without stories like these has not yet seen it in operation.

What it costs, and what it does not

For a mid-sized business, the sum is pleasantly short. On the credit side: no new licences, no migration, no training, no parallel running, no change in how the team works. The automation layer is small enough to test in full, and everything domain-specific lives in a configuration file rather than in the code: which abbreviation maps to which item, which surcharge tier applies when, all of it can be changed without calling a developer.

On the debit side stands honest engineering work: setting up interfaces, understanding the edge cases, testing, documenting. That is manageable next to a system change, but it is not zero. Set it against the two person-days a month, and you recoup the investment in months, not years, while keeping full control over your data, your workflow and your tool.

When a rebuild is still the right call

So this is not misread as a blanket recipe: there are good reasons for a new system. When the process itself is broken and not just the connection. When the legacy system has no interfaces and never will. When ten processes all point at the same outdated core at once. Then the thin bridge is only a plaster on a fracture. The order of the assessment stays the same regardless: first understand the process, then look for the smallest solution that carries it, and only when that demonstrably falls short do you talk about the big rebuild. Process first. Then tool. And a new system only if the bridge is not enough.