Stripe Customer Tax IDs and QuickBooks

A customer sends you their VAT number. You paste it into Stripe. The next invoice goes out with no tax on it, and a month later your accountant asks why.

The customer's tax ID is one of the highest-leverage fields on a Stripe invoice, because in the right circumstances it is the field that decides whether tax is charged at all. It is also one of the least understood, because three separate things are true about it at once: not every tax ID affects tax, Stripe checks the format but not the facts, and the value freezes onto the invoice the moment that invoice is finalized.

This post covers what the field is, what Stripe does and does not guarantee about it, and what actually reaches QuickBooks when the invoice syncs. That last answer is narrower than most people expect, and knowing where the line falls saves a lot of searching for a QuickBooks field that was never going to be there.

Start a free trial of Acodei if you want Stripe invoices and their tax lines landing in QuickBooks without the retyping.

What a customer tax ID is in Stripe

A tax ID in Stripe is a registration number belonging to the customer, stored on the customer record. A German company's VAT number, an Australian Business Number, a US EIN, a Canadian GST/HST number: all of these are tax IDs in Stripe's sense, each stored with a type and a value.

Stripe is direct about the primary reason the field exists. Its documentation describes displaying a customer's tax ID on invoice documents as "a common requirement that you can satisfy by adding tax IDs to customers," and states that "A customer's tax IDs display in the header of invoice and credit note PDFs."

So the baseline job is presentational and legal: many jurisdictions require the buyer's registration number to appear on a compliant invoice. That alone would make the field worth getting right.

A customer can hold more than one. The field on the customer record is a list, not a single value, which matters for businesses registered in several places. Each entry pairs a type enum with the number itself, and the type is not cosmetic. It is what tells Stripe which registry the number belongs to and, as the next section covers, whether the number has any effect on the tax calculation.

One operational detail catches people out. Stripe's documentation on managing tax IDs states the update path plainly: "To update a tax ID, delete the old ID and create another one." There is no edit in place. A correction is a delete followed by a create, which is worth knowing before you go looking for an update endpoint that does not exist.

The part almost nobody knows: not every tax ID changes the tax

This is the single most useful fact in this post, and it is buried in a column of a large table in Stripe's documentation.

Stripe's list of supported tax ID types carries a column headed "Impact in Tax Calculation," with a Yes or No against every single type. The footnote explains what Yes means: "Stripe Tax won't apply tax if this tax ID is provided, in line with the relevant laws."

Read that carefully, because it cuts both ways.

For the types marked Yes, supplying a valid tax ID is the mechanism that removes the tax. European VAT numbers are Yes. Australian Business Numbers are Yes. Canadian GST/HST and QST are Yes. UK VAT is Yes. Japanese Tax Registration Numbers are Yes. New Zealand GST is Yes. Indian GST is Yes. For these, the customer handing you a registration number is not a formality. It is the input that changes the amount you charge.

For the types marked No, the tax ID is recorded and printed and does nothing to the calculation. The most consequential example for US businesses: United States EIN is marked No. A US customer giving you their EIN does not make the sale tax free. Neither does a Brazilian CNPJ, a Mexican RFC, a Canadian BN, a Hong Kong BR number, a Chinese tax ID, a Colombian NIT, or a Polish NIP.

The practical failure this produces is a support ticket that reads "we entered the customer's tax ID and they were still charged tax." Usually nothing is broken. The type entered is simply one of the No rows, and the tax is correct.

The inverse failure is worse and quieter. A business sells into the EU, collects VAT numbers, and assumes the resulting zero-tax invoices are a bug or a setting. They are not. They are Stripe applying the reverse charge treatment the number triggered, and the invoices are right.

Exempt, none, and reverse

Alongside the tax ID list, Stripe carries a separate status on the invoice describing the customer's exemption. The invoice object exposes it as a field Stripe documents as "The customer's tax exempt status," with exactly three possible values: exempt, none, and reverse.

Those three are worth being able to tell apart, because they describe different reasons for the same visible outcome of little or no tax.

none is the ordinary case. The customer is a normal taxable buyer and tax applies as usual.

exempt says this customer is not taxable, which is the shape of a charity, a reseller with a certificate, or a government body.

reverse is the cross-border business-to-business case, and it is the one the VAT number produces. The liability moves to the buyer, who accounts for the tax on their own return. Your invoice carries no tax, and it is supposed to carry no tax.

An invoice with no tax on it is not self-explanatory. These three values are what tell you which of three quite different stories you are looking at, and they are the first thing to read when a zero-tax invoice needs justifying to somebody.

What Stripe validates, and the much larger thing it does not

Stripe validates some tax IDs automatically, and it is careful to scope what that validation means. The documentation opens the subject by assigning the responsibility clearly: "You're responsible for the accuracy of customer information including their tax ID number."

Then it adds the sentence that governs everything downstream: "The invoice includes the customer tax ID whether or not it's valid."

Nothing blocks. An invalid number goes onto the invoice PDF exactly like a valid one. If you were hoping the platform would refuse to issue a non-compliant invoice, it will not.

Three types get real registry checks:

• Australian Business Numbers are validated against the Australian Business Register.
• European VAT numbers are validated against the European Commission's VAT Information Exchange System, better known as VIES.
• UK VAT numbers are validated against HM Revenue and Customs.

For each of the three, Stripe repeats a limitation in nearly identical words. On EU VAT: "This process only validates whether or not the tax ID is valid, you still need to verify the customer's name and address to make sure it matches the registration information." On ABN, the same point: the check "only verifies the validity of the tax ID, and not whether the customer's name, address, and GST registration status match what's on the customers page in the Dashboard."

So a green tick means the number exists and is live. It does not mean the number belongs to the company you are invoicing. Matching the registered name and address against your customer is manual work that remains yours.

Two more limits are worth writing on a wall somewhere.

Outside those three types, Stripe "provides automatic validation to help determine if the formatting is correct," which is a format check rather than a registry lookup. Format checking catches a typo that breaks the pattern. It does not catch a well-formed number that was never issued.

And validation is a snapshot, not a subscription. Stripe states it directly: "However, we don't continue to validate them over time." A VAT number checked as valid in 2024 and deregistered in 2025 still reads as validated on your customer record. Nothing re-checks it. For a business whose zero-rating depends on those numbers being live, periodic re-verification is a real control that has to live somewhere in your process.

Because the checks run asynchronously, Stripe emits a customer.tax_id.updated event when a validation result lands. If you want to catch a failed verification rather than discover it during an audit, that event is the hook.

The value freezes when the invoice finalizes

Stripe copies a set of customer fields onto each invoice at finalization and stops updating them from then on. The tax ID list is one of them, and the language in the invoice object is precise: the field holds "The customer's tax IDs. Until the invoice is finalized, this field will contain the same tax IDs as customer.tax_ids. Once the invoice is finalized, this field will no longer be updated."

The exemption status carries the same treatment, in the same words.

The consequence is the one that produces awkward conversations. Correct a customer's VAT number today and every invoice already finalized keeps the old value permanently. The customer record is right, the historical invoices are wrong, and no edit to the customer will reach back and fix them.

This freezing behaviour applies to a whole group of customer fields, not just the tax ones, and the mechanics of what to do about an already-finalized invoice are covered properly in our post on revising a finalized Stripe invoice. The short version is that it is a procedure rather than a text edit.

There is a useful contrast sitting right next to it. Your own registration numbers on the invoice, as opposed to the customer's, live in a separate field that Stripe documents as "Only editable when the invoice is a draft." Both sides of the invoice lock down, they just lock at slightly different moments, and neither is editable once the document is real.

What actually carries into QuickBooks

Here is the honest answer, and it is worth stating plainly rather than dressing up.

Acodei's product documentation covers tax amounts and tax rates. It documents no destination in QuickBooks for the customer's registration number itself. If you are hunting for a QuickBooks field where the customer's VAT number appears because the Stripe invoice carried one, the documentation does not describe that mapping, and you should verify what your own QuickBooks file contains rather than assume it arrived.

That is a narrower claim than "it does not sync," and the difference matters. What is documented is the tax figures, and those are handled thoroughly.

Acodei's Tax documentation sets out three mapping approaches, resting on two possible sources of the tax data, and it closes the door on anything else: "Apart from the two options above, tax tracking from Stripe to QBO is not possible. Users must have either Stripe Tax enabled so we can retrieve rates and amounts or have it applied after the fact like in the case of VAT."

Either Stripe knows the tax and Acodei retrieves it, or QuickBooks applies it afterwards. There is no third source. The three approaches below are how those two sources land in your books.

Tax Product. Aimed primarily at US QuickBooks companies. All Stripe tax amounts roll into a single line item on the QuickBooks invoice or receipt, mapped to a non-inventory product pointing at a liability account. The reason it exists is a QuickBooks constraint rather than a preference: QuickBooks' US Sales Tax Center "does not allow third-party creation of official QBO tax rates," so aggregating into a product is the workable route. You then file from Stripe's own tax reports and pay down the liability account.

QuickBooks Tax Rate, described as Advanced. For non-US companies who want QuickBooks' own tax module. Each Stripe tax rate ID is mapped to a corresponding QuickBooks tax code, so a line taxed at GST 5% in Stripe lands on a QuickBooks line carrying the QuickBooks GST 5% code. Multiple Stripe rates on a single line item can be mapped to a QuickBooks group tax code, which is what makes combined GST and PST situations work.

Admin QBO Tax Mapping. For non-US companies that do not use Stripe Tax at all but still need tax on every line for QuickBooks reporting, with the tax applied after the fact in QuickBooks rather than carried from Stripe.

On the invoice itself, Acodei's Invoice Sync documentation describes creating a QuickBooks Invoice from a finalized Stripe invoice that reproduces every line item, and tax lines, as the mapping settings allow, with tax lines attached according to the approach you chose.

One validation is worth quoting accurately, because it is conditional and often repeated without the condition. Acodei compares the final invoice generated in QuickBooks against the Stripe invoice amount to confirm they match exactly, and that check applies only when tax is enabled. It is not an unconditional total check on every invoice.

Whether your prices carry tax inside them or add it on top changes how those totals line up, and that distinction has its own set of traps. Our post on inclusive versus exclusive tax covers the rounding and revenue consequences in detail.

What a bookkeeper should actually check

A short list, in the order that finds problems fastest.

1. Read the type, not just the number. Before concluding that tax was miscalculated, check the tax ID type against Stripe's Impact in Tax Calculation column. A US EIN on the record explains nothing about the tax charged, because that type is marked No.
2. Confirm the exemption status. For any zero-tax invoice, look at whether the status reads exempt, none, or reverse. It tells you which justification you are relying on.
3. Check the registration is still live. Stripe validated it once and does not re-check. If your zero-rating rests on a counterparty's VAT number, someone has to re-verify periodically.
4. Match the name and address yourself. A valid number proves the registration exists. It does not prove it belongs to your customer, and Stripe says so.
5. Fix the customer record and the open invoices separately. Correcting the customer does not touch finalized invoices. Those need their own treatment.
6. Reconcile tax amounts in QuickBooks, not registration numbers. Tax figures are what the sync is documented to carry. Verify those tie out, and treat the presence or absence of the registration number in QuickBooks as something to check in your own file rather than assume.

Two situations that look like bugs and are not

"Our EU customers are not being charged VAT." If those customers have valid EU VAT numbers on file and Stripe Tax is active, this is the reverse charge working. The invoices should show no VAT and the exemption status should read reverse. The thing to verify is that the numbers are genuinely valid and genuinely belong to those customers, not that the tax engine is broken.

"We added the customer's tax ID and they were still taxed." Check the type first. If it is one of the many types marked No in Stripe's table, including the US EIN, the tax is correct and the ID is doing its other job of appearing on the invoice PDF. Sales tax exemption inside the US works through exemption certificates and the customer's exempt status rather than through an EIN.

A third case is worth separating from both: tax that was never calculated at all, which is a different failure with a different fix. That one is covered in when a Stripe invoice cannot finalize because tax calculation failed. And if the tax was charged correctly but later refunded, tax on Stripe refunds is the one to read, because the refund path has its own constraints.

Where this fits

The customer's tax ID sits at an awkward junction. It is customer data, it becomes invoice data at finalization, it sometimes changes the money, and it is subject to a validation regime that is narrower than its green ticks suggest.

Getting it right is mostly a matter of knowing which of those four things is true in your case. Once the invoice is finalized, the value is fixed, the tax is what it is, and the accounting question becomes the ordinary one of making sure the amounts in QuickBooks agree with the amounts in Stripe.

If you want that last part to stop being manual, start a free trial of Acodei and let the invoices and their tax lines arrive in QuickBooks on their own.

Frequently asked questions

Does adding a customer tax ID in Stripe stop tax being charged?

Only for some types. Stripe's supported tax ID table carries an Impact in Tax Calculation column, and the footnote states that "Stripe Tax won't apply tax if this tax ID is provided, in line with the relevant laws." European VAT, UK VAT, Australian ABN, Canadian GST/HST and several others are marked Yes. A United States EIN is marked No, so adding one does not make a US sale tax free.

Does Stripe check that a customer tax ID is real?

Partly. Australian Business Numbers, EU VAT numbers and UK VAT numbers are checked against the Australian Business Register, VIES and HMRC respectively. Other types get a format check rather than a registry lookup. Stripe also states that "The invoice includes the customer tax ID whether or not it's valid," so an invalid number does not block invoicing, and that "we don't continue to validate them over time," so a validated number is not re-checked later.

Does a validated VAT number mean the customer is who they say they are?

No. Stripe is explicit that the check "only validates whether or not the tax ID is valid, you still need to verify the customer's name and address to make sure it matches the registration information." Confirming the registration belongs to your customer is manual work that stays with you.

Can I edit a customer's tax ID in Stripe?

Not in place. Stripe's documentation states: "To update a tax ID, delete the old ID and create another one." Doing so updates the customer record but does not change any invoice that has already been finalized.

If I fix a customer's VAT number, do old invoices update?

No. Stripe documents that the invoice holds the customer's tax IDs and that "Once the invoice is finalized, this field will no longer be updated." Finalized invoices keep whatever value was current at finalization, permanently. Correcting them is a separate procedure rather than an edit.

What do exempt, none and reverse mean on a Stripe invoice?

They are the three values of the customer's tax exempt status. none means an ordinary taxable customer, exempt means the customer is not taxable, and reverse means the reverse charge applies and the buyer accounts for the tax themselves. They are how you tell apart three different reasons an invoice might carry no tax.

Does the customer's tax ID appear in QuickBooks after the invoice syncs?

Acodei's documentation covers tax amounts and tax rates. It does not document a destination in QuickBooks for the customer's registration number itself, so treat that as something to check in your own QuickBooks file rather than something to assume. What is documented is that a finalized Stripe invoice creates a QuickBooks invoice reproducing the line items and tax lines according to your mapping settings.

How does Acodei get Stripe tax into QuickBooks?

Through one of three documented routes. Tax Product rolls all Stripe tax into a single QuickBooks line item mapped to a liability account, which is the usual answer for US QuickBooks companies. QuickBooks Tax Rate mapping assigns each Stripe tax rate to a matching QuickBooks tax code, for non-US companies using the QuickBooks tax module. Admin QBO Tax Mapping covers non-US companies that do not use Stripe Tax and apply tax in QuickBooks after the fact.

Sources: Stripe's Customer Tax IDs guide and Invoice object reference, both fetched at the time of writing. Acodei behaviour is grounded in Acodei's Tax and Invoice Sync product documentation.