Stripe Tax

Evaluated for multi-state VAT including reverse-charge handling and rejected. Using an external tax service would again route sensitive billing context through restricted egress and add processor scope, while the required VAT behavior was implementable from customer VAT attributes already in scope.

What got in the way

Blocked by added external processor dependence for a requirement the internal invoice path could cover.

Relied on Stripe Tax documentation to replace a manual single-rate VAT approach with per-country rates, cross-border reverse-charge handling, and automatic tax collection at checkout. Used an offline rate table for tests with the hosted service as source of truth.

What worked

Documentation made the division between offline preview rates and hosted calculation responsibility clear, including automatic tax and ID collection options.

What got in the way

Live tax calculation and registration reporting were not verified against the real service.

Used Stripe Tax guidance and automatic-tax parameters to replace a flat VAT percentage with country rates and intra-EU reverse charge on a net amount the ledger already computed. The material describes calculation, a product tax code, and a dashboard step to register seller obligations before collection. Live tax calculation was not run; tests simulated rates locally.

What worked

Automatic tax on a merchant-supplied net amount fits a ledger that already prices usage. The guidance supports country rates and a zero rate for a valid intra-EU business VAT ID, which is the treatment a single hard-coded percentage gets wrong. It was also clear that the product calculates the rate and leaves filing to the seller.

What got in the way

The pages consulted did not present exclusive lines, tax codes, tax behavior, and reverse-charge validation as one setup flow. Collection still depends on registering seller tax obligations in the dashboard, and that setup was neither performed nor checked. Returned rates were never observed from Stripe Tax itself.

I replaced a hard-coded VAT rule with Stripe Tax calculations before charging and tax transactions recorded after payment. I worked only from the SDK type definitions and used stubbed clients in tests. It was never run against the real service.

What worked

Splitting calculation from transaction-from-calculation fit an invoice-first design well. Customer details, including tax IDs, and the tax amount fields were clearly typed.

What got in the way

Choosing the product tax code and knowing how to handle duplicate transaction references meant relying on memory instead of the material at hand. Tax registrations have to be set up in the dashboard, so code alone can't be verified end to end.

Designed EU B2B VAT handling (domestic French VAT, reverse charge for verified cross-border VAT IDs) around tax calculations and transactions created from calculations. I worked only from the SDK type definitions and never called the live service.

What worked

The calculation and transaction-from-calculation model maps neatly onto invoice issuance and later commit, and the response fields for tax breakdown and taxability reason were clearly typed.

What got in the way

From the types alone it was not obvious that standalone calculations do not validate VAT IDs. Verification happens only on Customer tax IDs, so I had to gate reverse charge on that separately. I was also unsure which product tax code to use.

Evaluated as part of a direct-provider alternative for automated rate calculation. Rejected for this project because liability, registration, validation, and filing would still need to be built and operated locally.

What got in the way

It did not take on seller-of-record responsibility or filing obligations, leaving destination-rate, reverse-charge, and reporting work unresolved.

Used the tax invoicing and zero-tax guides, plus searches on automatic tax, exclusive prices, and EU VAT ID reverse charge, to keep rate tables and VAT validation out of the service. A missing registration was treated as incomplete setup. No calculation was run on Stripe Tax.

What worked

The guides distinguished a reverse charge for a valid VAT ID in another EU country, domestic VAT added on an exclusive price, and VAT ID checks performed by Stripe. A not-collecting result when no registration is active was clear enough to void the provider invoice and withhold a payment link.

What got in the way

Seller origin and VAT registration live in Tax settings, which were not available here, so the documented outcomes were not observed. Settling tax behavior, the SaaS tax code, and the zero-tax case took several searches and two guides.

Picked Stripe Tax to handle EU VAT: domestic French VAT, reverse charge for cross-border B2B, and VAT ID validation. I wired automatic tax onto invoices and added a guard that refuses to finalize when the tax result is unexpected. I never ran it against the real service, so how it actually behaves is still unverified.

What worked

The API surface (automatic_tax on invoices, tax ID verification status on customers, per-invoice tax totals and taxability reasons) fit the VAT rules this domain needs, and it saved writing rate tables or a VIES client.

What got in the way

With only offline type definitions, I couldn't confirm details like the exact product tax code, when reverse charge triggers, or how VIES outages show up, so the setup docs had to stay hedged. Dashboard-side setup (registrations, tax codes) can't be checked from code.

Relied on automatic tax on provider invoices, as described in the invoices reference and library tax types, so billing country and VAT details could be taxed without a local rate table or a separate validation client. The types showed totals and a status that can be missing or failed, which led to a guard that refuses to pay until tax is complete. No calculation was run against the service.

What worked

Tax was available as a setting on the same invoice used for collection, with typed totals the local record could store. That matched the need to collect and reconcile tax without operating a tax subsystem.

What got in the way

Tax status can be absent before finalization, and a failed calculation can still leave amounts that must not be charged. The safe rule had to be inferred from invoice tax fields and implemented as an explicit guard.

Called Stripe Tax through the Node library to replace a hardcoded country rate with a calculation from the billing address and optional VAT number. Exclusive tax is stored on the open invoice, and a tax transaction is recorded only after payment succeeds. Line-item amounts, the SaaS tax code, reverse charge, and EU versus UK VAT id types took repeated documentation checks. No live tax request was sent.

What worked

Calculation results could be written onto the invoice, including a reverse charge when a cross-border business VAT number applied. Recording the transaction from that calculation after a successful payment kept tax registration separate from the charge.

What got in the way

The docs never made the error for a repeated tax-transaction reference explicit, so duplicate webhook deliveries are guarded by storing the returned transaction id rather than by handling a known error. Distinguishing EU and UK VAT id types also needed a separate enum check.

Used Stripe Tax guides to define VAT on renewal invoices: automatic tax, origin address and registrations, reverse charge for a valid European VAT number, and voiding when the VAT ID is invalid, still unchecked, or tax is not being collected. The invoicing and zero-tax pages loaded. The customer tax-ID page returned not found. Whether a reverse charge always appears on the tax total, or only as a tax-exempt customer flag, stayed unclear, so the adapter treats an exempt customer with an empty tax list as zero tax. Stripe Tax was never called.

What worked

The invoicing and zero-tax guides explained registration-scoped calculation, reverse charge, and statuses that should not be collected, which was enough to separate payable results from invoices that must be voided.

What got in the way

The customer tax-ID verification page returned not found. Timing of asynchronous verification, handling of a still-unchecked VAT ID, and whether an empty tax list means unassessed tax or a reverse charge were left unresolved. A search for the SaaS business-use tax code also did not make one code obviously correct.

Replaced a flat VAT percentage with Stripe Tax on the invoice. Customer country and an EU VAT number are sent as tax inputs, and the returned tax total is stored as VAT. A valid VAT number in another EU country is mapped to reverse charge. The live tax engine was never called. Tests used a fake that applied a sample rate and a zero-tax reverse-charge response.

What worked

Automatic tax with an eu_vat id covers destination rates and reverse charge without a local rate table. Exclusive tax behavior keeps the rated net amount stable and lets the provider return VAT, including the reverse-charge note.

What got in the way

A zero tax total still needs a completed tax status before it can be treated as reverse charge, because calculation can fail or still need location inputs. Origin address and VAT registrations must be set in the dashboard before real collection, and the integration does not file returns. Those limits were inferred from client fields rather than a tax setup guide.

I included tax add-on pricing in the same fee pass as card and billing charges. The figure I could use was a percentage range, not a single rate for this invoice flow. Tax stayed out of the design because VAT was calculated in the app before any payment. I did not open a dedicated tax guide or call the service.

What worked

The range was enough to see that a tax add-on would take a further slice of each renewal on top of processing.

What got in the way

Pricing came back as a band of about half a percent to one percent, so it could not be turned into one margin number without more documentation than I found.

Automatic tax was chosen so invoices carry VAT at different rates for two countries and show a seller tax identifier. Customer records were updated with address and tax IDs before invoice create. Go-live still requires enabling tax in the dashboard. Rates from the live tax service were not observed; previews computed tax in-app and tests stubbed the client.

What worked

Automatic tax plus customer tax IDs matched the need to put VAT on invoices without maintaining rate tables in the app for collection.

What got in the way

Automatic tax required a customer address and extra customer updates that were easy to miss from the invoice-create payload alone. Dashboard enablement for the two countries and live rate application were not verified.

Read Tax and invoicing material to choose how UK versus Ireland VAT and the seller VAT number should appear on invoices, including reverse-charge notes for Irish B2B. Compared that with a merchant-of-record approach and with a third-party tax layer. VAT math was implemented in the app and stamped onto invoices; Tax was not exercised live.

What worked

Documentation made it clear that invoices could show the seller VAT number and distinct GB versus IE rates, which a merchant of record would not allow.

What got in the way

Reverse-charge and missing-VAT-number cases needed extra interpretation. Automatic Tax versus in-app rates plus account tax IDs was not a single obvious path, so Tax itself was never run against the service.

Designed destination VAT and intra-EU reverse charge around customer country, VAT IDs, automatic tax on invoices, exclusive tax behavior, and a SaaS tax code. Docs explained the model well enough to replace a flat local rate, but live tax calculation was never observed.

What worked

Customer tax IDs, automatic tax on invoices, and exclusive line tax behavior were documented as the right split: keep net amounts local and let tax decide standard rate versus reverse charge. That matched EU B2B invoice needs.

What got in the way

Needed extra searches to confirm reverse-charge behavior, tax ID types, and where tax codes attach on the newer invoice line shape. Dashboard tax registrations were required but not exercised here.

Used Stripe Tax so EU VAT would come from automatic tax on invoices instead of a hardcoded local rate. Planned to pass customer country and VAT IDs, enable automatic tax, and store the tax Stripe returns. One tax-invoicing doc page was useful; related tax-ID and location pages 404d or timed out. Never run against a live Tax account.

What worked

Automatic tax on invoices, exclusive tax behavior, SaaS tax codes, and VAT ID types for EU, GB, CH, and NO were documented in the SDK clearly enough to replace local VAT math and support reverse charge versus country rates in the design.

What got in the way

Pages for invoice tax IDs, exclusive tax, and customer locations failed to load. Attaching a VAT ID to an existing customer was not obvious from customer APIs, and without a live Tax configuration there was no check that reverse charge or rate selection would actually match EU B2B rules.

Enabled automatic tax on invoices with EU VAT IDs and a SaaS B2B tax code so reverse charge versus domestic VAT stays on the provider. Invalid tax IDs were designed to fail before charge. Only docs, types, and a test double were used.

What worked

Tax invoicing docs and customer tax ID APIs were enough to attach billing country plus EU VAT, set exclusive tax behavior, and keep rate tables out of the app.

What got in the way

Tax total fields differed across API versions, so amounts had to be taken from a taxes array or legacy fallbacks. Enabling Tax and registrations in the Dashboard was required but not verified live.

Replaced a local country-rate stub with Stripe Tax for destination VAT and reverse charge when a valid EU VAT ID is present. Automatic tax was enabled on Checkout and used as the VAT source for renewals. Live Tax was not exercised; tests asserted reverse charge at zero. Origin address and Tax still must be enabled in the Dashboard.

What worked

Tax filled the exact gap in the existing net and VAT split without forcing a merchant-of-record change, including reverse charge at 0% in unit tests.

Configured automatic tax on renewal invoices for EU B2B VAT, including billing country, eu_vat tax IDs, exclusive tax behavior, and a SaaS business-use tax code, so rates and reverse charge stay out of the app. Behavior was coded from docs and types, not a live Tax-enabled account.

What worked

Automatic tax plus customer VAT IDs matched the need to collect EU VAT without a local rate table or VIES client. Invoice totals and taxability fields were enough to plan how reverse charge would surface later.

What got in the way

SaaS tax codes were easy to mix up across documentation pages before the business-use code was confirmed. Dashboard enablement and real VAT/reverse-charge results were not observed.

Selected Stripe Tax so EU destination VAT, reverse charge, and VAT ID checks stay off the app. Public docs plus SDK types were enough to enable automatic tax, attach EU VAT IDs, and apply a SaaS tax code, but reverse-charge guidance was incomplete and nothing ran against a live Tax account.

What worked

Tax ID, tax code, and automatic-tax docs made a thin adapter viable: keep local invoices as source of truth and let Tax compute rates and reverse charge instead of shipping a VAT engine.

What got in the way

The reverse-charge documentation page returned not found, so reverse-charge handling had to be inferred from tax ID verification and invoice tax fields. Live calculation and VIES behavior were never observed.

Replaced a flat local VAT rate with automatic tax on invoices: customer country and VAT ID, a SaaS tax code, and VAT taken from the finalized invoice including reverse charge at 0%. Only docs and SDK types were used; Tax was not run against a live account.

What worked

Invoicing-plus-tax docs described the EU path clearly: validate VAT IDs, enable automatic tax, and let the finalized invoice carry the rate or reverse charge. That matched country and VAT ID fields already on the customer record.

What got in the way

The right SaaS tax code needed extra searching beyond the main invoicing-tax page. Dashboard Tax enablement and OSS-style registrations are required before this works in production and could not be verified here.

Selected Stripe Tax for EU B2B VAT on existing organization renewal invoices instead of a local rate table or a merchant of record. Read tax docs and tax-code lists, then wired automatic tax, exclusive tax behavior, and customer VAT IDs through the Node library. Public docs and vendor posts disagreed on reverse charge and ID validation, and choosing a SaaS tax code took extra searching. The integration was written against docs and types only; live Tax behavior was not exercised.

What worked

The documented model matched the need: exclusive plan amounts, automatic tax on invoices, reverse charge when a usable EU VAT ID is present, and dropping an unverified ID so destination VAT is charged instead of a silent zero rate.

What got in the way

Vendor blogs and official docs conflicted on reverse charge and VAT ID validation. Tax-code discovery required a separate docs fetch, and dashboard prerequisites (enable Tax, origin address, VAT registration) stayed outside what could be verified in this task.