Your Own Tax ID on Stripe Invoices and QuickBooks

Your accountant in Berlin returns an invoice you issued last quarter. The amount is right, the customer is right, the tax is right. It is still being rejected, because your own VAT number is not on it, and without your registration number the document is not evidence their client can use to reclaim the input tax.

That is a two-minute fix in Stripe and a permanent one on every invoice already issued, because the field freezes. This post is about the seller's side of the invoice: the registration numbers that identify you, where Stripe keeps them, the three-level rule that decides which of them prints, and what happens to any of it when the invoice syncs into QuickBooks.

The buyer's side is a different field with different behaviour, and we covered it separately in Stripe customer tax IDs and QuickBooks. If you are chasing a customer's VAT number, start there. This one is about yours.

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

The single most useful distinction: printing is not collecting

Almost every problem in this area comes from treating one thing as two names for the same thing. They are two separate objects, stored in two separate places in the Stripe Dashboard, and neither one implies the other.

Your account tax IDs live under Settings, Billing, Invoices, in the Invoice tax information section. Stripe describes their job in one line: "Displaying your tax IDs on invoice documents is a common regulatory requirement." That is the whole purpose. They are what gets printed in the header of the PDF.

Your tax registrations live somewhere else entirely, on the Locations tab of the Tax page. Stripe describes that job differently: you "must register with the tax authorities in the applicable jurisdictions, and add your registrations to Stripe," and "adding your registrations allows Stripe to calculate and collect the taxes you're responsible for remitting."

So one decides what appears on the document. The other decides what money Stripe collects. You can have either without the other, and both failure modes are real:

• A VAT number typed into the invoice settings, with no matching registration on the Locations tab, produces compliant-looking invoices carrying no tax. The number prints. Nothing collects.
• A live registration with no corresponding account tax ID produces correctly taxed invoices that omit your registration number, which is the Berlin scenario at the top of this post.

Before debugging anything else, open both screens and confirm the same jurisdiction appears on each. That check alone resolves most of what people bring to their accountant as an integration problem.

Where the numbers actually live

An account tax ID is a stored object, not a text setting, and that matters for how it behaves.

You add and remove them in the Dashboard, or through the tax ID create and delete endpoints. The scale allowance is generous: Stripe states you "can add up to 100 tax IDs to your account." That is deliberate. A business registered across a dozen EU member states plus the UK plus Australia can hold every registration number it owns without choosing between them.

It is worth noticing the asymmetry against the buyer's side, where Stripe allows "up to five tax IDs to a customer." Twenty times the headroom on your own side, because a seller accumulates registrations as it expands and a buyer rarely does.

Both sets end up in the same place on the finished document. Stripe: "Both the account and customer tax IDs display in the header of invoice and credit note PDFs." Yours and theirs, side by side, at the top.

The immutability that catches people out

Here is the sentence to internalise before you type a registration number into Stripe.

Stripe states it twice, in two different documents, in nearly identical terms. In the invoice customisation guide: "After you add a tax ID, you can't change the ID or type. To update a tax ID, delete it and add a new one." In the tax ID reference: "Tax IDs are immutable, you can't change the country and ID after you save the tax ID to your account."

There is no edit. A typo in a VAT number is not a correction, it is a deletion and a re-creation. That is mildly annoying at the account level and much worse at the invoice level, because of the second freeze.

On the invoice object, the field carrying your registration numbers is documented as: "The account tax IDs associated with the invoice. Only editable when the invoice is a draft." The tax ID reference says the same thing in plainer words: "You can't add, change, or remove account tax IDs after an invoice is finalized."

Put those together and the consequence is worth stating flatly. Every invoice you have already finalized carries whatever registration number was resolved onto it at the time, permanently. Fixing the account setting today fixes future invoices. It reaches back to precisely none of the ones already issued. If a quarter's worth of invoices went out with a wrong or missing number, the remedy is a commercial and jurisdictional question for your accountant, not a settings change.

This draft-only freeze is the same shape that governs custom fields, and if you have hit it there, the mechanism will be familiar. We covered that version in custom fields on Stripe invoices.

Three levels decide which number prints

If you hold registrations in several countries, the obvious question is which of them lands on any given invoice. Stripe answers it with an explicit priority order, and knowing the order is the difference between predicting the output and being surprised by it.

Stripe "uses the following priority when determining which of your account tax IDs appear on an invoice":

1. Manual override. Tax IDs "explicitly set using account_tax_ids on the invoice, subscription, payment link, or checkout session." Set them here and nothing else gets a say.
2. Automatic tax ID display. If enabled, "Stripe resolves the appropriate tax IDs based on the invoice's taxable location."
3. Default tax IDs. Your defaults "appear as a fallback."

Level two is the one worth understanding properly, because it is the only level that varies per invoice without anyone touching that invoice.

Stripe: "When you enable automatic tax ID display, Stripe resolves and stamps the most appropriate tax IDs at invoice finalization time, based on the invoice's taxable location. If you don't have matching tax IDs for the taxable location, we display the tax IDs of your head office location."

Three things in that sentence deserve attention. The resolution happens at finalization, which is exactly the moment the field also freezes, so the value is chosen and locked in the same breath. The input is the taxable location, not the customer's billing address and not your own country. And the fallback is your head office, which means an invoice into a jurisdiction where you hold no registration still prints a number, just not the one a reader might assume.

One prerequisite is easy to miss and stops the whole mechanism dead: "Automatic tax ID display requires automatic tax (automatic_tax[enabled]=true) on the invoice." If automatic tax is off on a given invoice, level two cannot run, and you silently fall through to your defaults.

That is the most likely explanation for the specific complaint "our German invoices show the wrong VAT number." Usually nothing is broken. Automatic tax was off on those invoices, level two never executed, and the account default printed instead.

Two neighbouring fields that are not this field

Three fields sit near each other on the invoice object and describe your business. Only one of them is a tax registration.

Account country is documented as "the country of the business associated with this invoice, most often the business creating the invoice." Account name is "the public name of the business associated with this invoice." Both are descriptive stamps. Neither is a registration number, and neither is a substitute for one on a compliant document.

The footer is the third, and it is the one genuinely worth knowing about, because it handles a class of number that is not a tax ID at all. Stripe, in its invoice customisation guide: "The footer field is often used for contractual or legally required text. A common use case is displaying legally required company registration information, such as a UK Companies House registration number."

A company registration number and a VAT number are different numbers issued by different authorities for different purposes, and many jurisdictions require both on an invoice. They also live in different Stripe fields. The tax one goes in tax IDs. The company one goes in the footer, or on a template, which we covered in the Stripe invoice template. Getting this wrong produces an invoice that satisfies half of a requirement.

If you invoice through Connect, the answer changes

On a platform, "your" registration number is an ambiguous phrase, and Stripe resolves it through the issuer.

The issuer field is "the connected account that issues the invoice. The invoice is presented with the branding and support information of the specified account." Stripe's Connect invoicing guide is explicit: Stripe "automatically pulls default tax IDs from the invoice issuer's account during finalization unless account_tax_ids is already set on the invoices."

So on a Connect invoice, the registration number that prints belongs to whichever account is issuing, not automatically to the platform. That is usually correct and occasionally the source of a surprise, and the mechanics of the field, including how it differs from a neighbouring field that looks like it does the same job, are covered in Stripe on behalf of.

Registrations expire, and they do not pause

One more piece of Stripe behaviour belongs here, because it affects whether the tax on the document matches the number printed on it.

Registrations carry a status. Stripe lists four: Collecting (Stripe is using it to calculate and collect tax), Scheduled (it will start on a future date), Expired (Stripe no longer uses it), and In progress (requested through Stripe but not yet active).

Two rules about changing that status are worth writing down, because both have caught businesses out.

First, expiry is one-directional in your books and not at all in the world: "Expiring a registration in Stripe Tax stops tax collection for that location, but it doesn't automatically deregister your account with the local tax authorities." Turning it off in Stripe does not end your obligation. Stripe is explicit that you should confirm with the authority first.

Second, there is no pause button: "You can't pause an active tax registration. To temporarily stop collecting tax in a location, you need to expire the registration and add it as a new registration when you want to restart collecting tax." And expiry is permanent: "If you re-register with local tax authorities, you need to add a new registration in Stripe."

None of this touches your account tax IDs. The number stays in your invoice settings and keeps printing whether or not the matching registration is still collecting. Which brings the post back to its opening point from the other direction: the two objects drift apart unless somebody keeps them together.

What reaches QuickBooks, and what does not

Now the honest part, which is narrower than most people hope and worth stating without decoration.

Acodei's product documentation covers tax amounts and tax rates. It does not describe any destination in QuickBooks for your own registration number. If you are looking for a QuickBooks field that filled itself in because the Stripe invoice carried your VAT number, the documentation does not describe that mapping, and you should check your own QuickBooks file rather than assume it arrived.

That is a deliberately narrow statement rather than a flat "it does not sync." What is documented is the tax figures, and those are handled thoroughly.

Your own registration number in QuickBooks is a company-level setting, and it always was, independent of any integration. Intuit's own VAT setup guidance walks through it as a step in setting up VAT: choose the month to start calculating from, the filing frequency, the accounting scheme, and then "enter your 9-digit VAT registration number." It is configured once, on the company, in the Taxes area. It is not a per-invoice value, which is precisely why nothing arriving on a per-invoice basis would populate it.

The regional split matters here too. A US QuickBooks company works through the Sales Tax Center; a non-US company works through the tax module that holds registration numbers and named tax codes. They are different modules with different capabilities, and Acodei's own approach to tax is shaped around that difference.

How the tax figures do arrive

Acodei's documentation names two possible sources for the tax data and closes the door on any third route explicitly: "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. From those two sources, three documented approaches:

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 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 that 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. Where two Stripe rates apply to a single line item, they 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.

One validation is worth quoting with its condition intact, because it is frequently repeated without it. 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.

If the tax you are chasing is on Stripe's fees rather than on your sales, that is a separate question with its own treatment in VAT and GST on Stripe fees.

A checklist worth running once a quarter

In the order that finds problems fastest.

1. Open both screens. Invoice settings for what prints, the Locations tab for what collects. Confirm every jurisdiction you trade in appears on both, or that you have a reason it appears on only one.
2. Check automatic tax ID display against your invoices. If it is on, confirm automatic tax is actually enabled on the invoices you care about. If it is off, your defaults are printing on everything and that may not be what you want across borders.
3. Read one finalized invoice PDF properly. Not the Dashboard summary, the PDF header. Your number and your customer's should both be there. This takes thirty seconds and is the only test that reflects what the customer received.
4. Confirm registration statuses. Anything reading Expired that should be Collecting means invoices are going out untaxed in that jurisdiction right now.
5. Check the footer separately. If your jurisdiction requires a company registration number as well as a tax number, the tax ID setting did not cover it.
6. Set your QuickBooks company tax number once and verify it renders. It is a company-level setting on your side of the integration. Nothing syncing per-invoice is going to set it for you.

The point

Two objects, two screens, two jobs. One prints your registration number on the document, the other decides whether Stripe collects tax at all, and Stripe will happily let you configure one without the other.

Both freeze harder than people expect. The number itself cannot be edited after it is saved, and the invoice's copy cannot be touched after finalization. So the cost of getting this wrong is not the fix, which takes two minutes. It is every document already issued while it was wrong.

Start a free trial of Acodei and let your Stripe invoices and their tax lines reach QuickBooks without manual re-entry.

Frequently asked questions

Where do I add my own VAT number so it shows on Stripe invoices?

In the Stripe Dashboard under Settings, Billing, Invoices, in the Invoice tax information section. Stripe describes account tax IDs as satisfying the fact that "displaying your tax IDs on invoice documents is a common regulatory requirement," and they render in the header of invoice and credit note PDFs. Adding one there does not affect what tax is calculated.

Why is my invoice showing no tax even though my VAT number is on it?

Because those are two different settings. The account tax ID controls what prints. Tax collection depends on having a registration on the Locations tab of the Tax page, which is what "allows Stripe to calculate and collect the taxes you're responsible for remitting." A printed number with no matching registration produces exactly this symptom.

Can I correct my own tax ID on an invoice I already sent?

No. Stripe states that "you can't add, change, or remove account tax IDs after an invoice is finalized," and the invoice field itself is "only editable when the invoice is a draft." Correcting the account setting fixes future invoices only. What to do about already-issued documents is a question for your accountant and the relevant tax authority.

Why does the wrong country's VAT number appear on some invoices?

Most often because automatic tax ID display did not run. It resolves the number from the invoice's taxable location at finalization, but Stripe requires automatic tax to be enabled on that invoice for it to work. Without it, resolution falls through to your default tax IDs. Stripe also displays your head office tax IDs when you hold no registration matching the taxable location.

How many tax IDs can I hold on my Stripe account?

Up to 100 on the account, against up to five on a customer. The generous account limit exists because a seller accumulates registrations as it expands into new jurisdictions.

Does my Stripe account VAT number sync into QuickBooks?

Acodei's product documentation covers tax amounts and tax rates, and does not describe a destination in QuickBooks for your own registration number. Check your own QuickBooks file rather than assuming it arrived. In QuickBooks your registration number is a company-level setting entered during tax setup, not a per-invoice value, so nothing arriving per invoice would populate it.

Where does my company registration number go, as opposed to my tax number?

In the invoice footer, or on an invoice template. Stripe names this use case directly: the footer "is often used for contractual or legally required text," with a UK Companies House registration number given as the example. It is a different field from tax IDs, and jurisdictions that require both need both configured.

On a Connect platform, whose tax ID prints on the invoice?

The issuing account's. Stripe pulls default tax IDs from the invoice issuer's account during finalization unless the invoice carries an explicit override, and the issuer is "the connected account that issues the invoice." On a platform, that is usually the connected account rather than the platform itself.