Automated Invoice Generation: Draft Before Send

Automated invoice generation is becoming a chat feature. In its August 2026 product update, QuickBooks said users in a limited beta could create invoices from an AI conversation and upload documents, spreadsheets or images as context. On 25 August, Sage announced on-demand invoice generation and draft invoice reviews in Sage Intacct Enhanced Billing Groups.

This is the right direction, but the verb "create" hides the important product decision. Does the system prepare a draft that a person can inspect, or does it issue and send an invoice because a prompt sounded complete?

My answer is firm: automated invoice generation should automate the draft first and earn the right to automate sending later. An invoice is a financial claim sent to another company. Once delivered, an incorrect customer, amount, tax treatment or bank detail becomes a real conversation, not a harmless suggestion.

The useful design is not human versus AI. It is a sequence in which software can move quickly while every irreversible boundary stays explicit.

What is automated invoice generation?

Automated invoice generation converts an approved business event into a structured invoice. The event might be a monthly subscription, a signed order, completed project work, an accepted time sheet or a row in an import file. The output is not merely a PDF. It is a record with a customer, line items, quantities, prices, dates, currency, tax treatment, payment terms and a unique number.

That distinction matters because document generation is easy. A model can produce a convincing invoice-shaped page even when it has guessed a field. An accounting system must instead refuse ambiguity. If the source says "consulting package" but contains no approved price, the correct result is a missing-value warning, not a plausible number.

A sound workflow therefore has four stages:

1. extract or receive facts from a known source;
2. map them into typed invoice fields;
3. validate calculations, required data and business rules;
4. create a reviewable draft, then trigger a separate send action.

The source and the invoice remain linked. When someone asks why the draft says 12 hours rather than 10, the answer should point to the approved time record, not to an opaque conversation history.

Can AI create an invoice from a prompt?

Yes, if "create" means prepare a draft and the prompt is treated as input, not authority.

A prompt is useful for intent: "Invoice Acme for the approved August design work, due in 14 days." It is poor at carrying every contractual fact. Which Acme entity is the customer? Which billing address and tax identifier apply? Was the work priced as a fixed package or by the hour? Does the agreement use euros? Has the customer requested a purchase-order reference?

The system should resolve those questions against structured records and show unresolved choices. It may suggest the likely customer or line item, but suggestions must stay visibly different from confirmed values. This is the same reason we argue that AI accounting accuracy claims need an audit trail: a confident answer is not evidence of a correct posting or invoice.

QuickBooks' August update illustrates both the opportunity and the boundary. Uploaded documents and spreadsheets can remove manual entry, while its billing workflow keeps drafts and reminders subject to approval. Sage's new billing controls likewise pair generation with draft invoice reviews. The market is not simply removing people from invoicing. It is moving people from typing every field to reviewing exceptions.

Which invoice fields must be explicit?

The source determines how much automation is safe. A recurring template is not equivalent to a free-form message, even if both eventually produce the same PDF.

At minimum, the invoice system needs an unambiguous customer, issue and due dates, currency, line descriptions, quantities, unit prices, discounts, tax rates and the applicable treatment for special cases. It also needs numbering and duplicate protection. Those are not details to recover after the PDF is sent.

This does not require a human to click every field forever. It requires a confidence policy based on evidence. Stable, repeated fields can graduate to automatic handling. New or conflicting fields stay in review. The system should expose why an invoice was considered routine and which rule allowed the next action.

The broader pattern resembles a good tool boundary. In our work on tools we did not write, the difficult part was not calling a function. It was deciding which system owns the truth, what the tool is allowed to change and how failure is made visible.

What did Norman measure in real invoices?

We checked nearly 4,000 invoices issued by German businesses through Norman during the last twelve months. We defined a simple path narrowly: one line item, euros, 19% VAT, no discount and no reverse-charge treatment.

More than four in five invoices departed from that simple path in at least one way. Roughly one in eight had multiple line items. Others used a different VAT rate, more than one rate, another currency, a discount or reverse-charge treatment.

This is not an error-rate study, and it does not show that an AI system would fail on those invoices. It measures structural variety. The result is still important: the invoice that looks like a standard template in a demo is not representative enough to define the production control boundary.

Norman therefore exposes invoice creation and invoice sending as separate actions. Creation assembles typed fields, validates them and produces the document. Sending is another decision. The same separation appears in our approach to accounts receivable automation: exact financial state belongs to deterministic systems, while AI is most useful for context and exceptions.

Separating the actions also improves recovery. A rejected draft can be corrected quietly. A sent invoice may need a cancellation, replacement, customer explanation and bookkeeping follow-up. The cost curve changes sharply at send.

When can automatic invoices be sent without review?

Automatic sending is reasonable when the business can describe the eligible case without using words such as "usually" or "probably".

A good candidate is a recurring invoice derived from an approved template, with unchanged customer master data, deterministic service dates, fixed pricing and known tax treatment. The system should also confirm that no duplicate exists, the source period is complete and the customer has not been blocked or changed since the previous run.

Everything else starts with review. That includes a new customer, a new line item, a changed price, an unusual currency, multiple tax rates, a missing purchase-order reference, a contract amendment or a conflict between source documents. Review does not need to mean reading the whole invoice. It should focus the person on the values that changed or lack evidence.

There are three useful automation levels:

• draft every invoice and require approval;
• auto-approve only a named, measured class while reviewing exceptions;
• send a narrow class automatically, with monitoring and a rapid stop control.

Teams should move between levels using observed results, not a vendor setting labelled "autonomous". Before enabling automatic sends, replay historical cases, compare every generated invoice with what was actually issued and inspect false approvals separately from unnecessary reviews. A false approval has external cost. An unnecessary review mostly costs time.

How should you test automatic invoicing software?

Start with your own difficult month, not the vendor's clean demonstration. Include new and recurring customers, discounts, multi-line work, credit corrections, different tax rates, foreign currency, incomplete source data and duplicate-looking records. Remove the final outcome, then ask the system to produce drafts and explain its evidence.

Score at least five things:

• field accuracy before any manual correction;
• calculation and tax-rule validation;
• duplicate detection and numbering integrity;
• quality of the exception queue;
• false sends, or cases the system would have sent incorrectly.

Also test the operating history. Can you see which source supplied each important field, who approved the invoice, what changed between draft versions and exactly when it was issued and sent? Can an administrator pause automatic sending without disabling draft generation? Can the system retry a failed delivery without creating a second invoice?

Finally, separate automation coverage from automation quality. A product can boast that it generated 95% of invoices while humans silently repaired half of them. Measure the share that passed unchanged, the time spent per exception and the external corrections required after sending.

Automated invoice generation is valuable because it removes repetitive assembly and directs attention to the unusual cases. It becomes dangerous only when a smooth conversation is mistaken for complete evidence. Make the draft fast, make the validation strict, and make sending a distinct permission. That is how invoice automation becomes infrastructure rather than a demo.