How to automate invoice generation, and the three places it breaks

Almost every business that automates invoicing arrives from the same place. Somebody spends the last working day of the month retyping numbers into a template, it takes a day and a half, and it is obviously a waste of a person. That instinct is correct. What follows it usually is not, because the document was never the hard part, and a team that automates only the document ends up with a faster way to produce invoices that still do not reconcile against anything.

So the useful question is not how to automate invoice generation in general. It is which of three specific things is broken at your company, because the answer is the difference between two days of work and two months.

The three places invoicing actually breaks

Every invoicing process has the same three stages, and they fail independently:

• The inputs. What was delivered, to whom, at what price. This lives in timesheets, delivery notes, a CRM, or somebody's memory of what was agreed on a call.
• The record. The invoice number, the date, the amounts, and the fact that this invoice exists and is unpaid. This is the part an auditor, a tax authority and your own cash flow all depend on.
• What happens next. Sending it, chasing it, marking it paid, and matching a bank transfer back to the right invoice.

Only the middle one is really about a document. If your pain is the first stage, a template generator will move the typing earlier rather than remove it. If your pain is the third, you need a ledger and a reconciliation view, and the PDF is incidental. Naming the stage before choosing the tool is most of the decision, and it is the same discipline as scoping a software project before anyone writes code.

Start with where the numbers come from

If the amounts are assembled by a person reading three places and doing arithmetic, automating the template saves the typing and keeps the arithmetic. That is a small win on the slowest, least risky part of the job.

The real move is to make the thing being billed a record in its own right at the moment it happens, rather than a reconstruction at month end. A delivered job, a shipped order, a logged hour. Once those exist as rows, the invoice becomes a query rather than a document somebody assembles, and the month end job collapses from a day and a half to a review. If those rows currently live in a shared spreadsheet, that migration comes first and has its own traps, set out in migrating from spreadsheets to a database without losing the history.

This is also the honest reason invoicing automation is often the second project rather than the first. It depends on operational data that many small companies do not yet capture anywhere, which is the broader argument in internal tools for a small business, and when to stop using Excel.

The numbering rule that is not negotiable

Invoice numbers must be sequential, without gaps, and never reused. A cancelled invoice is corrected with a credit note, not by deleting the row and reissuing the number. This sounds like bookkeeping pedantry until the first time somebody asks you to account for a missing number.

It is also the single most common defect in a homemade invoicing tool, and it has a specific cause: the number gets allocated at the moment the PDF is rendered. Then a render fails and burns a number, or two people click at once and both get 1043. Allocate the number from the database inside the same transaction that creates the invoice record, and render the document afterwards from that record. The document is a view of the row. The row is the invoice.

The same principle decides what you store. Store the amounts, the tax treatment and the customer details as they were on the day, not as a join to a customer table that somebody will edit next year. An invoice is a historical claim, and it must not change quietly because an address was updated.

In Egypt the invoice is no longer really a document

If you invoice in Egypt this stops being an internal design question. The Egyptian Tax Authority runs two parallel systems: electronic invoices for business to business transactions, submitted in a structured format with an electronic signature, and electronic receipts for business to consumer sales, transmitted from point of sale or ERP systems integrated with the ETA central platform. The rollout has been staged by decision, and Thomson Reuters tracks the sequence of those decisions, including Decision No. 281 of 2025, which brought a further group of taxpayers into the e-receipt mandate from 15 September 2025 and required their point of sale or ERP systems to be integrated with the central system.

There is a second reason to care. Egypt's small enterprise tax regime under Law No. 6 of 2025 offers businesses with turnover up to EGP 20 million a tax charged as a small percentage of turnover rather than on profit, in bands EY summarises as running from 0.4% to 1.5%, and integration with the tax authority's electronic systems, electronic invoicing included, is one of the conditions. So electronic invoicing is not only a compliance chore, it is attached to the rate you pay.

The practical consequence for a build is blunt. Do not write your own submission layer as step one. The structured formats, the signing requirements and the wave schedules change, and an integrated provider absorbs that churn for a monthly fee that is far below what maintaining it costs you. Build the part that is specific to your business, which is the inputs, and let the document and the submission be somebody else's problem.

What is worth automating first

In order, and stopping when the pain stops:

• A record of the billable thing at the moment it happens, with the price attached.
• A draft invoice generated from those records, which a person reviews and approves. Review stays in for longer than you expect.
• A ledger view of what is issued, unpaid and overdue. This is usually the change people notice.
• Sending, then reconciliation against the bank. Last, because both are easier once the first three are true.

Note what is not on that list. Automatic sending without review is the feature everyone asks for first and the one most likely to send a wrong number to your largest client. Keep a person in the loop until the drafts have been right for a couple of months.

When not to build this at all

Three honest cases. Under roughly twenty invoices a month, the retyping is annoying rather than expensive and a template plus your accounting package is the correct answer. If your billing is genuinely standard, off the shelf accounting software already does all of this, and better. And if the real problem is that invoices go out late because nobody decides they are ready, software will show you a red row and change nothing.

There is also a prior question that decides the shape of everything above: whether you bill on a retainer or per project. The two produce different invoicing rhythms and different cash flow, and BDG Labs has the honest comparison in B2B retainer versus project pricing. Settle that before you automate around one of them.

If the month end pain turns out to be reporting rather than billing, that is a different and usually cheaper project, and it is scoped in automating manual reporting without buying a BI platform.