Stripe's Billie Can Now Take a VAT Number on Every Renewal. It Still Can't Promise the Renewal Gets Approved.

We wrote in September about the catch buried in Stripe's Billie integration: it's single-use. Every renewal on a Billie-financed subscription gets its own real-time credit decision, with no stored credential and no guarantee that an approval today means an approval next cycle. Stripe just shipped the first concrete lever against that exact problem. On September 30, Billie picked up two new optional parameters — company_details and reference — and Stripe's own documentation says plainly that supplying them "can improve authorization rates." That's not a new feature so much as a patch aimed at the specific gap the single-use design leaves open.

That number is Billie's own reported upside for turning the method on at all — it's not a stat about these two new fields specifically, because no such number exists yet; the release is a week old. But it's the right context for why Stripe bothered shipping something this narrow. Billie is working well enough as a checkout option that the renewal-approval gap is now the thing worth closing, not the method itself.

What actually shipped on September 30

company_details is an object carrying registered_name, registration_type, registration_number, vat, and registered_address — the structured legal identity of the buyer's business, as opposed to whatever free-text company name your signup form happened to collect. reference is a plain string identifying the specific transaction. Both are optional and additive; nothing about an existing integration breaks if you ignore them.

They don't land on the same set of objects, though, and the gap matters:

A one-off Billie purchase gets both fields. A subscription gets only one — and it's the one that happens to be the one worth having. reference is a reconciliation convenience: a string you can match against your own records for a single transaction. company_details describes the buyer's legal identity, which doesn't change from renewal to renewal the way a transaction ID does. It's the field that feeds directly into whether Billie approves the charge, and it's the one Stripe extended to the exact resource — Subscriptions — where the single-use, re-underwritten-every-time problem actually lives.

Why a VAT number is a lever on an approval decision at all

Billie's underwriting isn't a one-time onboarding check that then rubber-stamps everything after it. It's a fresh credit and fraud decision on every transaction, run against whatever data Stripe passes at the moment of that specific charge. We covered this mechanic in detail in our first Billie piece: there's no stored "Billie account" that, once approved, keeps approving. Each renewal is its own application.

What an underwriting engine does with ambiguous input is make a more conservative call, or route the transaction to manual review, or decline outright — not because the buyer is necessarily a bad risk, but because the signal it received wasn't clean enough to confirm who it's actually extending credit to. A free-text company name typed into a signup form ("Acme Corp" when the registered entity is "ACME GmbH & Co. KG") is exactly that kind of ambiguous input. A structured registration_number and vat field, matched against a commercial registry or VIES lookup, is the opposite: a specific legal entity Billie can verify against its own records instead of guessing from a string a human typed during checkout.

None of this is specific to Stripe's phrasing — "can improve authorization rates" is a hedge, not a promise, and it should be read as one. Billie isn't disclosing a specific lift number, and there's no reason to expect one; credit decisions for a brand-new, well-documented legal entity and a decade-old one with a clean registry history aren't going to move by the same amount. What Stripe is saying, functionally, is that the engine making this decision performs better with cleaner inputs, which is true of essentially every underwriting model and is exactly why this shipped as an API change rather than a Dashboard setting.

Repurchase rate is the figure worth sitting with for a subscription business specifically. An 18% lift in repurchase for a one-time-purchase merchant is a nice-to-have. For a company billing on Billie every month or every year, "repurchase" is just another word for "renewal" — and renewal is precisely the event this release is trying to protect.

What this doesn't fix

Three limits are worth being explicit about, because it's easy to read "can improve authorization rates" as "solves the renewal problem" and it doesn't.

It's still a fresh decision every time. Better data makes that decision more likely to go your way on average. It doesn't make the decision go away, and a long-standing customer whose business circumstances changed — a new entity structure after a merger, a VAT re-registration, a change of registered address — can still get declined on a renewal that looks routine from your side.

It doesn't apply retroactively. Nothing changes on a subscription that's already running until you explicitly call Subscription update with payment_settings.payment_method_options.billie.company_details populated, or set it at creation for new subscriptions going forward. If your integration went live in August when Billie first shipped, every subscription created before you add this field is renewing without the benefit of it, silently, until someone goes back and patches them.

It only works if you collected the data in the first place. A signup form that asks for "Company name" as one free-text field has nothing to map to registered_name, registration_type, registration_number, and vat as four distinct values. Most B2B SaaS signup flows weren't built assuming they'd eventually need a structured legal-entity record, because until now nothing downstream cared about the difference between a trade name and a registered entity. This release is the first concrete reason to care.

What to actually change this week

• Audit your B2B signup form for structured company data. If you only capture a free-text business name, add fields for legal registered name, registration number, and VAT ID — at minimum for any customer who selects Billie at checkout or renewal.
• Backfill company_details on existing Billie subscriptions. Don't wait for the next renewal to find out an update call would have helped. If you have the registration data on file from a sales or KYC process, push it onto the subscription now via Subscription update.
• Treat stale company data as a renewal risk, not just a CRM hygiene issue. A customer who changed legal entity, merged, or moved their registered address since signup is exactly the profile likely to see company_details that no longer matches what's on file — flag these for a refresh before their next billing date, not after a decline.
• Keep segmenting Billie declines separately in your churn reporting. We said this in the first piece and it still holds: a Billie-declined renewal is a credit decision, not a support ticket or a sign the customer wants to leave. Route it like you'd route any other decline code — to whoever owns renewal recovery, with its own fallback path, not into a generic "payment failed" bucket next to your card and net-terms failures.

This is a genuinely useful release, and it's useful specifically because it's narrow. Stripe didn't change what Billie is — it's still a single-use, re-underwritten-every-time payment method, and nothing here turns it into something that behaves like a stored card. What it did was hand you the one input most likely to be missing from your own data: a clean, verifiable business identity instead of a name a human typed into a form once. If Billie renewal declines have been showing up in your involuntary churn numbers as an unexplained category, this is worth testing before you write them off as unavoidable — run the segment through our churn calculator to see what even a partial reduction in Billie-specific declines is worth over a year, because a credit decision you can influence with better data is a different problem than one you can't influence at all. And whatever share of renewals clear or don't clear underwriting, the subscribers who reach a cancel page on purpose still need somewhere to land — which is the part a cancellation flow handles regardless of which payment rail got them there.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.