Who writes an affiliate's invoice, and how self-billing works

The problem, stated simply

You pay €642 of commission to an affiliate. On your side it is an expense: you want to deduct it. On theirs it is income: they have to declare it. Neither of you can prove it with a row in a third party's dashboard.

So a document is needed. And the first question — the one almost nobody asks before they get audited — is: who issues it?

The default answer is the affiliate. They are the one selling a referral service, so they are the one who should draw up the invoice. In practice this almost never works: you have a hundred affiliates, sixty of them individuals, spread over twelve countries, and you will not get a hundred correct invoices every month.

Self-billing, and its one condition

Self-billing reverses the direction: you draw up the invoice, in the name and on behalf of your affiliate, from the amounts you are paying them. You already know every figure, so the document is correct by construction.

Every tax authority that allows it sets the same condition, and it is the one people forget:

You need the prior agreement of the person in whose name you are invoicing.

Prior means before the first invoice, not after. That agreement has to be traceable: a date, an address, a record of who gave it. A verbal agreement, or a ticked box you keep no record of, is worth nothing on the day somebody asks.

Which is why consent to self-billing is given from the affiliate's own portal, with its date, and not from yours. Nobody can consent on somebody else's behalf.

And when the affiliate has not agreed

An affiliate who does not answer, or who refuses, must not block their own payment. They get a receipt instead: same amounts, same period, same payout reference — but the document attests to a payment rather than declaring a service in their name.

The difference is not cosmetic. An invoice issued in the name of someone who has not consented is a document they did not want, with tax consequences they did not choose. Issuing a receipt is the only correct way out.

Numbering, and why it must have no gaps

A series of invoices has to be continuous: 0146, 0147, 0148. A missing number is the first thing an audit looks at, because a gap means either a deleted invoice or an undeclared one.

That has a direct consequence for the software: you never delete an invoice. Ever. Including when it is wrong, including when the payout did not end up happening.

What you do instead: the credit note

A credit note is a negative invoice, numbered in its own series, that explicitly names the invoice it cancels. Invoice 0148 stays, credit note 0031 says it is cancelled, and the two sum to zero. The history is readable, and there is no gap.

That is exactly what has to happen when a transfer comes back — more common than people think with PayPal, where an address with no confirmed account leaves the payment unclaimed for thirty days before the funds return. The invoice was issued, the payment did not happen: that calls for a credit note, not a deletion.

VAT, in three cases

This is not tax advice, but the cases are few enough to name. What decides is the affiliate's country and their status — individual or business.

• A business in your own country. The local rate applies, and it appears on the invoice.
• A business in another EU country. Reverse charge: no VAT on the invoice, with the corresponding wording and both parties' VAT numbers.
• An individual, or a business outside the EU. The rules differ, and it is the status declared by the affiliate that decides. Which is a good reason to ask them at signup rather than guess later.

Note in passing the difference between a registration number (company number, SIREN) and a VAT number: a small trader below the VAT threshold has the first without having the second. Electronic invoicing requires the first on every invoice.

Electronic invoicing: a PDF will not be enough

Several European countries are making structured invoices mandatory — a file a machine reads, not only a human. The standard is EN 16931, and the two formats that implement it are UBL and CII.

In practice that means that alongside the PDF there has to be an XML carrying the same information as fields: both parties' identities, registration numbers, net amounts, rates, mandatory wording. If your platform only produces a PDF, somebody on your side will be retyping that data manually.

What a platform has to produce, in short

• A document per payout, written at the moment of the payout — not a monthly export reconstructed afterwards.
• An invoice if the affiliate consented to self-billing, with the date of that consent; a receipt otherwise.
• Gapless numbering, per issuing entity and per year.
• A credit note when a payout comes back, never a deletion.
• VAT handled according to the affiliate's country and status.
• A structured file alongside the PDF.
• A statement over a period, on both sides: yours across all your affiliates, theirs on themselves.

None of this is exotic. It is simply work somebody has to do, and it had better be the machine, at the moment the funds leave.

Read next