Missing invoice numbers: check the billing population before changing revenue

A gap in an invoice sequence is a useful exception to investigate. It is not, on its own, evidence of an unrecorded sale. Equally, a sequence with no gaps can conceal an invoice that never reached the accounting system.

The practical control is to reconcile the billing system's document population with the accounting records. Number sequences help you find exceptions within that work. They should not decide the accounting entry.

Before generating a list of missing numbers, establish which system issued the invoices, which entity or account owns each sequence, and when that system assigns a number. Retain the relevant numbering settings and any documented change during the review period.

For example, Stripe supports both customer-level and account-level numbering. In its Connect setup, different connected accounts using on_behalf_of can issue the same displayed prefix and suffix. A displayed invoice number therefore should not be your only matching key across accounts. See Stripe invoice numbering documentation.

Use a key that includes the originating system, the relevant account or entity, and the system's stable invoice identifier. Keep the displayed number as a separate field. This lets you distinguish a genuine duplicate from two documents that happen to look alike in a spreadsheet.

Ask the billing-system owner three specific questions:

Do not assume that a blank spot between two numbers must contain a deleted invoice. Invoice-numbering requirements also vary by jurisdiction. This reconciliation does not determine whether a company's numbering policy complies with local requirements.

Choose a review cutoff and retain a source export that includes document identifiers, dates, customer, currency, face amount, status and links to replacements or credits. Include finalized invoices that have since been voided, rather than filtering them out before the review begins. Keep drafts identifiable but separate from issued documents.

These distinctions are real system states, not interchangeable descriptions. In Stripe, a draft can be deleted, finalization moves a draft to open and ensures an invoice number is present, and an open invoice can move to void. Treating all those events as issued invoices would distort the population. See Stripe invoice status and finalization documentation.

Export the accounting records independently. If you use the ledger to build both sides of the comparison, you cannot discover a source invoice that never arrived there. Record the accounting export's entity, date filters and extraction time as well.

Decide whether you are reviewing documents issued during a period or the cumulative population as of a date. Do not silently mix the two. Capture later changes separately so that a void entered tomorrow does not rewrite the evidence of what the reviewer saw today.

Suppose a hypothetical billing system has assigned numbers 1001 through 1010 to ten finalized documents. There are no sequence gaps. For this example, “live” means finalized and not voided; it does not mean unpaid. Amounts are document face values, not the receivables balance. At the review cutoff, the population looks like this:

The $19,000 total is a document-population control, not current billings or revenue. Excluding the void leaves nine live invoices with a face amount of $18,000. The accounting matches cover eight invoices and $16,000, leaving one $2,000 exception.

A sequence-only test would have passed. The source-to-ledger comparison finds the missing posting.

Before recording anything, trace that invoice through the integration log and search for a manual entry or alternate reference. Confirm the entity, currency, amount and customer. If it is genuinely absent, correct the failed handoff through the approved process and retain the new accounting transaction reference. Do not post a second invoice merely because the external invoice number was not carried into the ledger.

A compact exception register can contain the source key, displayed number, document status, face amount, expected accounting treatment, matched ledger reference, investigation result and owner.

For a missing number, the outcome might be a documented numbering change rather than a transaction. For an apparent duplicate, it might be two different issuing accounts. A source invoice with no ledger match might reveal a failed import, an incorrect date filter or a posting in the wrong entity. Each explanation needs its own evidence.

Review the reverse direction too: accounting invoice records with no match in the chosen source population. Some may come from an authorized second billing channel. Others may be manual duplicates. Add legitimate channels to the scope rather than declaring unmatched ledger records acceptable as a group.

Credit notes, cancellations and replacement invoices need linked references. Retain their separate identities so that a correction does not look like two live charges, or a void does not look like an unexplained omission. Do not create dummy invoices, renumber history or change dates merely to make the sequence report look tidy.

The final workpaper should show the source population, exclusions by reason, matched counts and amounts, outstanding exceptions and evidence of completed repairs. Run amount checks separately by currency. Preserve both source exports and the matching rules so another reviewer can reproduce the result.

Even a fully reconciled invoice population does not prove that all revenue has been recorded correctly. Work can be performed before invoicing, and an invoice can precede the recognition of revenue. The guide to revenue recognition for service and project businesses addresses that separate decision.

The narrower conclusion is valuable enough: every document in the defined billing population has an explained accounting outcome, and every apparent gap has been investigated rather than converted into an unsupported entry.