Stripe Invoice Numbering and the Number QuickBooks Shows

Every Stripe invoice carries a number that Stripe guarantees is unique. Every QuickBooks invoice carries a number too. When the same sale exists in both systems, those two numbers are frequently not the same string, and the difference is not a bug in either product.

It is worth being precise about where the difficulty actually lives, because the usual diagnosis is wrong. Stripe's numbering is not loose. Stripe states plainly that "the full invoice number is always unique across your account in both schemes." The problem is that uniqueness inside Stripe says nothing about uniqueness inside QuickBooks, and QuickBooks contains records Stripe never created: the invoice your office manager keyed in last Tuesday, the estimate that got converted, the annual retainer somebody raises by hand every January.

Two systems, two numbering namespaces, one overlapping set of documents. This post is about how Stripe composes its number, why your account is on the numbering scheme it is on, and what to expect on the QuickBooks side when the sync writes the record.

If you want finalized Stripe invoices arriving in QuickBooks with line items, tax and payments intact, you can start a free trial.

The number has two parts, and only one of them moves

Stripe's own framing is the useful one: "Stripe automatically generates invoice numbers to help track and reconcile invoices. Invoice numbers have a prefix and suffix, such as 586A2E-0139 or MYSHOP-1203."

Read those two examples side by side and the entire system is visible. 586A2E is a machine-assigned prefix. MYSHOP is one somebody chose. The four digits after the hyphen are a sequence counter. The prefix identifies a scope, the counter increments within that scope, and everything else in this post follows from the question of what the scope is.

On the invoice object, the composed result lives in number, documented as "a unique, identifying string that appears on emails sent to the customer for this invoice. This starts with the customer's unique invoice_prefix if it is specified."

Note what that definition ties the number to: emails sent to the customer. The invoice number is a customer-facing artifact first and a reconciliation key second. That ordering explains several of the constraints below, and it is also why the field is nullable. In Stripe's own documented example of a draft invoice, number is null. A draft has no number because a draft has not been issued to anybody.

Which sequencing scheme you are on was decided by your country

Stripe supports two schemes, and most businesses never chose between them.

Customer-level. "Uses a unique prefix for each customer and assigns invoice numbers sequentially for a given customer." Every customer gets their own prefix and their own counter. Stripe's worked example: a customer named Typographic might get the prefix TYPGRA, so their invoices run TYPGRA-0001, then TYPGRA-0002, and so on.

Account-level. "Uses the same prefix for every customer and assigns invoice numbers sequentially across your entire account." One prefix, one counter, shared by everyone. Stripe's example uses a business called Rocket Rides with the prefix RKTRIDE: the first invoice is RKTRIDE-0001, "a second invoice to a different customer would be RKTRIDE-0002, another invoice to the first customer would be RKTRIDE-0003, and so on."

Now the part that surprises people. You did not pick one of these. Stripe did, based on where your business is:

Stripe chooses a default behavior based on the country your Stripe account is based in. European Union member countries and the United Kingdom typically require account level sequencing. All other countries default to customer level sequencing because it doesn't expose the total number of invoices.

Both halves of that sentence are worth sitting with, because they are in tension and the tension is the point.

Account-level sequencing produces a single unbroken series across the business, which is what an unbroken-sequence invoicing requirement generally asks for. It also means the number on any invoice tells an observant customer roughly how many invoices you have issued. RKTRIDE-0007 is a company with six previous invoices, and anyone receiving it knows that.

Customer-level sequencing hides that. Each customer sees their own count and learns nothing about anyone else's. Stripe names this explicitly as the reason it is the default outside the EU and UK: the scheme "doesn't expose the total number of invoices."

So the same design decision reads as a compliance requirement in one jurisdiction and an information leak in another, and your account inherited whichever answer your address implied. For a US business wondering why customer invoice numbers restart at 0001 for every new client, that is the whole explanation. Nothing is broken. That is the documented default.

One operational note attached to switching. Stripe is explicit that changes are not retroactive: "When switching between schemes or updating prefixes, only future invoices use the new settings. This doesn't impact existing invoices." A business that changes scheme has, from that day forward, two numbering conventions in its history and no way to normalize the old ones. Plan the change at a period boundary, and write down the date you made it, because in three years nobody will remember why the format changed mid-year.

Prefixes have rules, and one of them is a trap

Both schemes accept a custom prefix, and both constrain it identically. Stripe states that prefixes "must be between 3 and 12 characters" and "can't match any other customer prefix, including prefixes that are no longer in use."

That final clause is the one to notice. It is not simply saying prefixes must be unique among your current customers. It is saying the prefix namespace never releases anything. A customer you offboarded in 2023 still holds their prefix. If a new client arrives with a similar name and you reach for the obvious abbreviation, Stripe may refuse it for a reason that is invisible in your customer list, because the holder is not in your customer list any more.

The practical consequence is that prefix schemes based on customer names collide sooner than anyone plans for. Three-letter and six-letter abbreviations of company names are not as distinctive as they feel, and once a prefix is spent it stays spent. If you are setting a convention for a growing book of customers, build in something that will not run out.

On the account-level side, Stripe assigns the account-wide prefix for you, and overriding it has a version requirement worth knowing before you promise anyone a format change: modifying the account prefix "requires that your account's default API version is at least 2020-03-02."

Starting somewhere other than 0001, and the ceiling nobody expects

By default, Stripe says, "invoice numbers start at 0001." Most businesses migrating onto Stripe Invoicing do not want that, and Stripe supports the obvious alternative, with a documented example: a user who "left off at invoice number 123 in their old system" can "resume the invoice number at 124."

How you set it depends on your scheme, which is a small detail that costs people an afternoon. On customer-level prefixes, the starting number is set per customer, on the Customer details page in the Dashboard or through the next_invoice_sequence parameter on the customer. On account-level prefixes, it is a single account-wide field, "Next invoice sequence," in Invoice settings. If you are on customer-level numbering and looking for one global setting to continue your old series, you are looking for something that does not exist in that scheme.

Two constraints bound the field. The first is monotonic: "you can only set the next invoice number to numbers greater than any numbers used on an invoice." You cannot rewind to fill a gap.

The second is a hard ceiling, and it is the reason to think about this at migration time rather than later:

The maximum allowed invoice number is 1,000,000,000 regardless of how you set it. Use the lowest value possible so that you don't reach this limit.

A billion is not a number most businesses approach by invoicing. It is a number businesses approach by encoding something into the sequence. Anyone tempted to make the counter carry meaning, a year, a branch code, a customer id, is spending headroom on data that belongs in the prefix or in metadata, and Stripe's advice to "use the lowest value possible" is aimed squarely at that impulse.

Connect puts you in somebody else's sequence

If you invoice through Stripe Connect, there is a further layer, and it changes which counter is even being used.

Stripe: "When creating invoices with the on_behalf_of parameter, Stripe uses the connected account as the merchant of record." From that follows a set of consequences the docs list explicitly:

• "Each connected account has its own invoice numbering sequence that starts at 0001."
• "Invoices for the same customer from different connected accounts (specified using on_behalf_of) can have the same invoice number prefix and suffix."
• "The merchant of record determines which invoice sequence is used, not the platform account."

The middle bullet is the one that breaks reconciliation scripts. Two genuinely different invoices, for the same customer, can carry the identical number string, because they were issued in two separate sequences. Uniqueness in Connect is per merchant of record, not per platform. Any process that treats the invoice number as a primary key across a platform's whole book of business is relying on a property Stripe does not offer, and it will work fine right up until two connected accounts both reach the same counter value.

If you are running a platform, the safe key is the invoice id, which is unique globally, with the number kept for what it is good at: appearing on a document a human will read.

Three numbers that all look like invoice numbers

Reconciliation conversations go wrong when people say "the invoice number" and mean different fields. There are at least three in play, and they are not interchangeable.

number is the invoice's own number, the composed prefix-and-sequence string described above, and the one that appears on the invoice document.

receipt_number is different, and it is the sharpest confusion available on this topic. Stripe documents it as "the transaction number that appears on email receipts sent for this invoice." Same invoice, second identifier, attached to the receipt rather than the invoice. It appears on the object right alongside number, it is also nullable, and it will happily be picked up by anyone building a mapping from a field list rather than from the documentation. A receipt number matched against an invoice number will simply never reconcile.

The QuickBooks document number is a third thing entirely, living in a different system with its own rules. It is the reference number that appears on the QuickBooks sales form, and QuickBooks maintains it independently of anything Stripe does. Whether you can set it yourself is governed by the Custom transaction numbers setting, under Account and settings, then Sales, then Sales form content. Intuit describes it as letting you "set your own numbering preference," which "adds an Invoice number field where you can enter any number or letter format you want."

The collision this post opened with lives precisely here. QuickBooks will reject a second document that reuses a document number it already holds. It does not care that the number arrived from Stripe, and it has no view of Stripe's uniqueness guarantee, because that guarantee was only ever about Stripe.

What Acodei does to the number on the way in

Acodei's documented behavior on this is narrow and worth stating exactly rather than generally.

When a Stripe invoice is finalized, Acodei creates a QuickBooks Invoice that reproduces every line item, and tax lines, as your mapping settings allow. On creating it, Acodei stores the Stripe id against the QuickBooks invoice id, and applies suffix rules to avoid duplicate numbers.

Those suffix rules are a setting. Invoice Number Suffix appends -AC1, -AC2 and so on to every invoice, and its documented purpose is exactly the namespace collision described above: preventing "duplicate number" errors when users hand-enter invoices in QuickBooks. It is on by default, and Acodei's own best-practice guidance is to keep it enabled if anyone on your team sometimes raises invoices directly in QuickBooks.

There is also a validation rule alongside it: Acodei compares invoice numbers to prevent duplicate invoices from being created in QuickBooks. A separate validation compares the finished QuickBooks invoice against the Stripe invoice amount to confirm they match exactly, and that one is documented as applying only when tax is enabled for the account, which is a condition worth carrying rather than dropping.

And one documented limitation, which is the honest edge of the mechanism: automated suffixing does not protect against manual renaming of invoices in QuickBooks. The suffix defends the number at the moment of writing. It does not defend it afterwards from a person with edit rights.

Two of our existing guides go deeper than this section does, and they are the right next stop rather than a rehash. What a Stripe invoice resync does covers numbering across a rebuild, including that renaming gap. Stripe invoice revisions in QuickBooks covers what happens when a revision puts two numbered documents in the file for one commercial transaction. For the wider duplicate question, including what the check can and cannot see, what duplicate protection actually checks is the canonical treatment.

Matching records across the gap

A short, practical sequence for anyone reconciling the two sides.

Match on the id, display the number. The Stripe invoice id is globally unique and immutable. The number is neither: it is absent on drafts, scoped to a merchant of record under Connect, and altered on the QuickBooks side by the suffix. Use the id as the key in anything automated, and treat the number as the human-readable label it was designed to be.

Expect the suffix, and read past it. A Stripe invoice numbered INV-2041 appearing in QuickBooks as INV-2041-AC1 is the mechanism working. If you search QuickBooks for the bare Stripe number and find nothing, search on customer and amount instead.

Do not match a receipt number against an invoice number. They are different fields for different documents. If a mapping was built from a field list rather than the docs, this is the first place to look.

Check your scheme before drawing conclusions about gaps. Under customer-level sequencing, every customer's series starts at 0001 and increments only when that customer is invoiced. A series that looks full of holes at the account level is usually just several customer series interleaved.

Write down the date of any scheme or prefix change. Since the change is not retroactive, your archive will contain both conventions permanently, and the boundary date is the only thing that explains it later.

Treat a renamed QuickBooks invoice as a broken link, not a formatting choice. It is outside what the numbering logic protects, and it is the one case where the two systems can silently stop pointing at each other.

FAQ

Why does my QuickBooks invoice number end in AC1?

That is Acodei's Invoice Number Suffix setting, which appends -AC1, -AC2 and so on to synced invoices. Its documented purpose is to prevent "duplicate number" errors when invoices are also hand-entered in QuickBooks. It is on by default. It is a formatting difference, not a mismatch, and if you are matching Stripe invoices to QuickBooks invoices by number you should expect it.

Why do my Stripe invoice numbers restart at 0001 for every customer?

Because your account is on customer-level sequencing, which assigns a unique prefix per customer and counts sequentially within that customer. Stripe chooses the scheme from your account's country: EU member countries and the UK typically require account-level sequencing, and all other countries default to customer-level because it "doesn't expose the total number of invoices."

Can I make Stripe invoice numbers continue from my old system?

Yes. Stripe documents the migration case directly: a business that left off at 123 can resume at 124. Set it per customer with next_invoice_sequence if you are on customer-level prefixes, or in the account-wide "Next invoice sequence" field in Invoice settings if you are on account-level. You can only set it to a number greater than any already used on an invoice.

Is the receipt number the same as the invoice number?

No. Stripe documents number as the identifying string that appears on emails sent to the customer for the invoice, and receipt_number as "the transaction number that appears on email receipts sent for this invoice." They are two different identifiers on the same object, and matching one against the other will not reconcile.

Why was my invoice prefix rejected as already in use?

Prefixes must be 3 to 12 characters, and Stripe states they "can't match any other customer prefix, including prefixes that are no longer in use." A prefix held by a customer you stopped invoicing years ago is still held. The conflicting record may not appear anywhere in your active customer list.

Do two Stripe invoices ever share the same number?

Within a single account and scheme, no: Stripe states the full invoice number is always unique across your account in both schemes. Under Connect it is different. Each connected account has its own sequence starting at 0001, and Stripe notes that invoices for the same customer from different connected accounts "can have the same invoice number prefix and suffix." On a platform, use the invoice id as your key.

Does Acodei check for duplicate invoice numbers in QuickBooks?

Acodei's documented validation compares invoice numbers to prevent duplicate invoices from being created in QuickBooks, and the Invoice Number Suffix setting exists to keep synced numbers from colliding with numbers entered by hand. The documented limitation is that automated suffixing does not protect against an invoice being manually renamed in QuickBooks afterwards.

Does an invoice have a number before it is finalized?

Not necessarily. The number field is nullable, and Stripe's own documented example of a draft invoice shows number as null. Since the number is defined as the string that appears on emails to the customer, a document nobody has been billed for has nothing to carry yet.

The short version

Stripe composes an invoice number from a prefix and a sequence, and the scope of that sequence, per customer or per account, was chosen for you by the country your account is based in. Inside Stripe, the result is guaranteed unique. Outside Stripe, that guarantee does not travel, and QuickBooks holds its own numbering and its own hand-entered records, which is the collision the suffix setting is documented to prevent.

The reconciliation rule that falls out of all of it is simple: key on ids, read numbers as labels, and never assume the number in one system is the number in the other.

If you would rather your finalized Stripe invoices arrived in QuickBooks with the line items, tax and payments already in place, start a free trial or see how the pricing works.