LAST REVIEWED: 2026-08-06 — product behaviour below verified against the codebase, not inferred from support history.

SUPERSEDES: the "Tax/VAT: general guidance only" line in Fees & deductions — Internal, and the tax answers in both FAQs articles.

Follow this order. Do not skip to the rate.

Two classes of statement, opposite handling:

Do not hedge a FACT. Do not assert a RULE as a conclusion about this person.

Disclaimer discipline: exactly one, at the end. Never open with it. Never repeat it.

STEP A — Is this VAT proper, or tax-adjacent? Tax-adjacent = withholding tax, tax residence certificates, W-9/W-8/1099, vendor onboarding packs, bank certificates, e-invoicing mandates. Go to §4.2. Most of these escalate.

STEP B — Which payment method? Card (Stripe) / Bank transfer / Wallet. If unknown, ask. Everything downstream depends on it.

STEP C — Which document are they looking at? On bank transfer and wallet there are two. If they quote a number or say "the invoice", confirm which. Do not discuss rates before this is settled. This is the single most common cause of a wrong answer.

STEP D — Determine CUSTOMER using §2.

STEP E — Determine treatment using §3, comparing the creator's country against CUSTOMER's country.

STEP F — Run §7, then §6, then answer from §5.

CUSTOMER = the counterparty on the creator's own invoice. It is not always the brand.

Verified in code: the payment method enum is exactly stripe, bankTransfer, wallet. Wallet is a peer payment method, not a sub-case of bank transfer. Merchant of Record is Creator for Stripe and Passionfroot for the other two.

Consequence — memorise this. On bank transfer and wallet, the brand's country is irrelevant to the creator's invoice. Only the creator's country matters, compared against Germany. A creator asking "the brand is in the US so why is there VAT?" on a bank transfer deal has misidentified their customer.

Consequence for brands. A brand's supplier is Passionfroot GmbH on bank transfer and wallet, and the creator on card. Do not tell a brand their supplier is always Passionfroot.

Compare creator's country against CUSTOMER's country (from §2).

Vocabulary — do not compress these:

This is the highest-frequency question shape. Read the row, then answer from §5.1.

Shortcut that is always safe on bank transfer and wallet:

Send close to verbatim. Adapt names and figures only.

On Passionfroot, the first thing to check is who your invoice is actually between, because it isn't always the brand. If the brand paid by card, your invoice is to the brand. If they paid by bank transfer or wallet, Passionfroot is the merchant of record to the brand, and your payout invoice is between you and Passionfroot GmbH in Berlin — so the comparison is against Germany, not the brand's country.

From there, the general pattern is: same country as your customer → local VAT normally applies. Different EU countries → normally handled as reverse charge. Customer outside the EU → normally outside the scope of EU VAT.

In your case that makes your customer [CUSTOMER], so this is [treatment].

Close with §9.

First establish which document. Then:

There are two invoices on bank transfer and wallet collaborations, and they legitimately show different VAT:

Invoice for sponsor — between Passionfroot GmbH and the brand. We issue this one, and the VAT reflects our position with them, not yours. Reference only.

Seller payout invoice — between you and Passionfroot GmbH. This is yours, and the one for your accounting.

They can share a number, so a brand invoice at 0.00 alongside your payout invoice at your local rate is normal — both can be correct.

If VAT was applied and paid, state the arithmetic as FACT (this wording worked):

Invoice [ID] shows €[net] net + €[vat] VAT ([rate]%) = €[total], and that full €[total] was paid out to you. The VAT wasn't dropped or withheld — it was calculated, added on top of your net fee, and included in the payout you already received.

If no VAT was entered, go to §5.3.

Verified behaviour. Auto-invoicing hardcodes the rate to 0% — not "blank", an explicit 0. autoInvoice is on by default, so this is the default outcome, and it's why an invoice can show an explicit "0% VAT" line. The manual path shows an "Apply VAT" toggle that is off by default, with a "VAT rate" field that has no prefilled value.

Scope — do not overstate this. The creator-entered rate only drives the brand-facing invoice when the brand pays by card (Stripe), where the creator is Merchant of Record. On bank transfer and wallet, VAT on both documents is derived from country automatically and is unaffected by the auto/manual setting.

VAT is set by you when you request payment: Payments → select the collaboration → Request payment, then switch on Apply VAT and enter a VAT rate. The toggle is off by default and the rate isn't prefilled, so nothing is added unless you set it — there's no account-level default and no automatic calculation.

One thing that catches people out: if the collaboration is set to invoice automatically, the invoice is generated with VAT at 0%. Auto is the default. To control the figure yourself, set the proposal to Manual and request payment from the Payments tab.

For the invoice that's already wrong: if it hasn't been paid, open it in Payments and Void it, then send a fresh payment request with the correct VAT. If it has been paid, send me the invoice ID.

Root cause, verified in code — this is the answer, and it is not what support has been saying. A VAT ID saved in settings does not flow into the Request payment modal. On a card/Stripe invoice the creator's VAT ID comes only from a field they retype in the modal. So a creator who saved it in settings and then requested payment gets an invoice with no VAT ID, having done everything right. Two separate places, no link between them.

The field is behind a second toggle: Customize invoice → "Your Tax ID" (placeholder "Enter Tax ID"). Easy to miss because it sits under a toggle that sounds cosmetic.

Also true, and worth saying before they go looking: on bank transfer and wallet collaborations the creator's VAT ID cannot appear on the brand-facing invoice, because Passionfroot is the seller on that document — it prints our VAT ID (DE350317246) and the brand's. The creator's own VAT ID appears on their payout invoice, taken from settings.

You're right that a reverse charge invoice normally needs both VAT IDs, and this is a gap on our side rather than anything you've configured wrongly.

The specific cause: saving your VAT ID in settings doesn't carry it into the payment request. For a card invoice you also have to switch on Customize invoice in the Request payment modal and enter it in Your Tax ID. Two places that should be one — I've flagged it.

For bank transfer and wallet collaborations, your VAT ID appears on your payout invoice (from your settings), not on the brand-facing one — that invoice is issued by Passionfroot, so it carries our VAT ID and the brand's.

Where the settings live: Settings → Payments → Invoices, section "Value Added Tax / Goods and Services Tax". Don't tell a creator to look for "VAT ID" — that string isn't the row heading.

Do not defend. This has been a production bug.

Send me the invoice IDs and I'll get these looked at. This has been wrong on our side before — we found a defect that applied the reverse charge note where it shouldn't have been, fixed it, and regenerated the affected invoices. So this may well be the same thing rather than a misunderstanding on your accountant's part.

Escalate. Set expectations: previous fix took roughly 3 weeks over two rounds.

Never say it cannot be corrected. We have manually reissued invoices — four for one creator, nine for a brand.

I can't change an issued invoice from the app, but that's a product limitation rather than the end of the road — send me the invoice ID and I'll get it to the team who can reissue a corrected document.

Separately, so this doesn't recur: set your default billing details in your payment settings using your registered legal entity name, and future invoices will be issued to the right entity.

If they cite national law (UStG, UStDV, KSeF, etc.): do not argue the law back. Escalate immediately with:

I'm not going to try to interpret [country] tax law at you — you know your obligations better than I do. Let me get this to the team who can issue a correction document.

Not from the app — an issued invoice can't be edited, and voiding only works on unpaid invoices. Send me the invoice ID and what it should say, and I'll get it to the team who can reissue. Please don't assume it's impossible; we've reissued invoices before.

Escalate.

Reverse charge means the VAT doesn't disappear — it changes hands. Instead of you collecting VAT and passing it to your tax authority, your customer reports it themselves in their own VAT return. It's the standard way cross-border business-to-business services are handled inside the EU, so a seller doesn't have to register for VAT in every country their customers are in.

In practice it's applied where you and your customer are in different EU member states and your customer gives you a valid VAT ID — without one, a supplier would normally charge their own local VAT. When it applies, the invoice needs the words "Reverse charge", or the equivalent in your language, plus both VAT IDs.

Do not apply §3. Do not confirm or deny.

Whether a small-business scheme applies to you is something I can't determine — it depends on your registration and your turnover, and your accountant or local tax authority is the right place to confirm it.

What I can tell you is how it interacts with Passionfroot: a scheme like that can mean no VAT on your domestic invoices, but it doesn't generally change how a genuine cross-border supply is treated. And whatever the answer, the VAT figure on your Passionfroot invoice is whatever you enter at the Request payment step — we don't calculate it for you.

FACT. State plainly.

Passionfroot GmbH
Chausseestraße 40A, 10115 Berlin, Germany
VAT ID: DE350317246

We're a German company, so we don't have a US EIN — the VAT ID above is the equivalent identifier for invoicing.

That's a legitimate request. Passionfroot doesn't currently collect W-9 or W-8 forms through Stripe, so when a brand needs one for their own tax reporting, you'll need to provide it to them directly.

If you're a non-US creator, a W-8 is generally requested regardless of the payment amount. Thresholds like the USD 600 1099 reporting line affect what the brand has to file, not whether they can ask you for the form.

Payment-method dependent. Do not give a blanket answer.

It depends how you're paying. On bank transfer and wallet payments, Passionfroot is the merchant of record — so for your finance and legal teams your supplier is Passionfroot GmbH, and you don't need to onboard each creator separately. On card payments the creator is the merchant of record and invoices you directly, so there your supplier is the creator.

Verified in code. VAT is charged at top-up, based on the brand's billing address country, and is deliberately not charged again when they pay a creator from the balance. In practice it's 19% only for German-billed brands; every other country gets 0% with a reverse-charge remark. Top-ups produce a document either way — a Passionfroot PDF for bank-funded top-ups, a Stripe invoice for card.

VAT is applied when you load balance into your FrootWallet, based on your billing address country, and you'll get an invoice for the top-up itself. It's charged at that point precisely so that paying creators from your balance doesn't add VAT again — that's why those invoices show no VAT line.

If your billing address is outside Germany you'll have seen 0% with a reverse charge note on the top-up rather than a VAT amount.

Caveat for the creator side: the creator's payout invoice still carries their own VAT, based on their country, exactly as on bank transfer. "No VAT on wallet payments" is true of the brand-facing invoice only — never say it to a creator about their payout.

Keep the "must" where it is genuinely law: the words "Reverse charge" and both VAT IDs are required on a reverse charge invoice. Do not soften those.

Escalate — do not attempt an answer — when any of these is true:

When escalating, always capture: invoice ID(s), payment method, creator country, brand country, and what their accountant specifically said.

These are real defects. Don't defend them, don't invent a workaround beyond what's written here.

Our PDFs print English only — either "Reverse charge VAT ID: [id]" or "Reverse Charge". There is no localisation anywhere in the product. The local-language equivalents (Steuerschuldnerschaft des Leistungsempfängers, btw verlegd, autoliquidation de la TVA) are accepted by member states, but we don't print them. Do not tell a creator their invoice carries the note in their own language. If their accountant requires the local-language wording, that's an escalation.

One, at the end, never repeated:

This is general information about how VAT is usually handled on cross-border collaborations, not tax advice — your accountant or local tax authority can confirm what applies to your specific situation.

When the reply was mostly about a specific invoice:

The figures above are what our system generated and why; how you report them is something your accountant can confirm.

Retrieval aid. Each row lists phrasings customers have actually used, then the section to answer from.