How to Invoice Lead Buyers and Automate Partner Billing in 2026
An invoice number is a boundary. Before it, a draft can change silently; after it, every correction needs its own document. The decisions that follow from that, including the two most home-built billing systems get wrong.
Counting leads is the part everyone expects to be hard, and it is the easy part. What makes billing lead buyers difficult is that an invoice is a legal document and a delivery log is not. The moment you put a number on a document, you leave the world where things can be quietly corrected and enter one where every change needs its own paperwork.
Almost every billing system built in-house gets the same two things wrong, and both come from missing that line.
The number is the boundary. Before it, a draft is a calculation over unbilled deliveries and a returned lead simply disappears from it, with nothing to correct and nothing to explain. After it, the same return needs a credit note, and if the invoice has already been paid you owe a refund. Design the two states separately, and never let a draft become a stored record or a running period become a document.
Why a general invoicing tool does not fit
Tools built for fixed-price products and hourly work assume a stable line item. Lead billing does not have one:
- The volume is different every period, per partner. There is no flat amount to invoice.
- Every buyer has their own price, and often more than one: a different rate per lead type, or a price that follows a field on the lead.
- Leads come back. Returns and rejections have to reduce the bill, and the way they do it depends entirely on whether the invoice has been issued yet.
- Both sides keep their own count. Your log says 347 delivered, the buyer says 339. Without one shared record of what left and when, every invoice becomes a negotiation.
The result is the familiar month-end: export the delivery log, cross-reference prices in a spreadsheet, subtract what came back, build documents in a second tool, then chase payment from a third place.
Two states, and the number between them
A draft is not a document. It is a sum over the deliveries in a period that have not been billed yet: a grouping, not a record. It is tempting to store drafts as rows, and that is the wrong call. A stored draft is a cache that can go stale, and it brings three failure modes with it: drafts that survive a run, drafts pointing at deliveries that have since been billed elsewhere, and a discard that fails halfway through.
Compute the draft on demand instead. Then a return during the open period costs no paper at all: the line is simply not there any more.
After the number, nothing is edited. A correction is a credit note that references the original. And there is a third case that gets forgotten: if the original invoice has already been paid, the original stays paid, because that is what happened and the money did move, while the credit note stands open as a refund you now owe.
One more thing the number forces you to handle: a delivery that arrives after the run. Do not reopen the closed invoice. Issue a supplementary invoice for the same period, and put the words on the document itself, "Supplement to September 2026", as stored text rather than something derived at print time. A receipt carries what was true when it was issued, and a period name computed later depends on a language setting that is allowed to change.
- 44 records, September
- 4.180,00 €
- Returned inside the deadline, 2 records
- −190,00 €
The two questions people conflate
This is the most common and most expensive bug in home-built billing, and it is worth stating precisely:
- Which period does a delivery belong to? Its delivery date decides.
- When does that period become a document? The cut-off decides.
Treat those as one question and you get this, which is a real defect from a real system: clicking "invoice run" on 7 September produced a September invoice covering 1 to 7 September. The same click on 3 October produced a second September invoice, covering 1 to 30 September. The same period, billed twice.
The cause is not the button. It is the assumption that a period still running can be invoiced at all. The fix is that a period is not due until its cut-off has passed, and without due there is no number, and without a number there is no document. Then add the index that answers "does an invoice for this partner and this period already exist?", because that question is what stops a second run from writing a second document.
Do the date arithmetic in the account's timezone, not UTC. A period that starts at two in the morning is not a rounding error in something that computes deadlines.
Pricing, per partner
Two shapes cover most agreements and both are straightforward to enforce:
| Shape | How it works | Use it for |
|---|---|---|
| Fixed per lead | One amount for every delivered lead under this agreement | Consistent lead quality, simple contracts |
| Rate times a field | The price is a rate multiplied by a value on the lead | Loan amount, system size, contract value |
Different prices for different lead types fall out of this for free, because the agreement is per lead type rather than per partner: the same buyer takes exclusive leads under one rule and shared leads under another.
"$15 for the first hundred, $12 after that" sounds like one more pricing option. It is not, because the price of a delivery stops being a property of that delivery and becomes a function of everything else in the period. A tier boundary crossed on the 20th reprices deliveries from the 3rd, which means a draft that changes retroactively, and a return that moves you back below a threshold reprices them again. If you build it, decide in advance whether the tier is evaluated at delivery time or at billing time, and write the answer down. We support fixed and rate-times-field, and this page is not going to list a tier model we do not have.
Tax, in four cases decided from three facts
The three facts are your own country of establishment, the buyer's country, and whether the buyer has a VAT identification number. From those, four outcomes:
| Case | When | Rate |
|---|---|---|
| Standard | Buyer in your own country | Your local rate |
| Reverse charge | Buyer in another EU country with a valid VAT ID | Zero, with the mandatory note on the invoice |
| Export | Buyer outside the EU | Zero |
| Exempt | Your own situation makes the supply exempt | Zero |
Store the case, not just the rate. Two of those four produce zero percent, and when you reconstruct an invoice a year later "zero because reverse charge" is a completely different statement from "zero because export". The electronic formats need different markers for them too, so a stored rate of zero is not enough information to reissue the document.
It is a tempting shortcut and it fails silently. A pattern that recognises three countries quietly falls back to your standard rate for every other one, which means charging domestic VAT on a supply that should have been zero-rated, on a document you cannot correct without a credit note. Treat a missing country as a gap on the partner record and refuse to run until it is filled. Naming the gap before the run is the whole point: the alternative is a confident, wrong invoice.
Keep the list of EU member states as visible data with a date on it rather than hidden in a helper. It changes every few years by one entry, and whoever edits it is editing a tax decision.
Electronic invoicing, concretely
ZUGFeRD and XRechnung are not two data models. They are two profiles of the same one: EN 16931, expressed in UN/CEFACT CII syntax. What differs is what actually leaves your system:
| Format | What goes out |
|---|---|
| ZUGFeRD, also called Factur-X | One PDF/A-3 file with factur-x.xml embedded inside it |
| XRechnung | The XML alone, with no PDF, because a PDF would be a second version of the same invoice |
Two practical details that cost time if you learn them late. XRechnung requires a buyer reference, the EN 16931 field BT-10, which in the German public sector is the routing identifier the buyer gives you; an invoice without it is rejected. And CII is a sequence, not a bag: elements in the wrong order fail validation even when every value is correct.
The requirement that matters more than either format, though, is this one: a failed electronic invoice has to be visible. The common failure is a system that exhausts its attempts quietly, leaving an invoice that looks complete while the machine-readable part is missing, which the buyer's accounting system discovers rather than you. Give the invoice an explicit state, off, generated, or failed with a reason, and show it in the list.
Gapless numbering is an obligation, not a nicety
In Germany, § 14 UStG requires a sequential invoice number, and that requirement drives three design decisions:
- The run locks rather than computing in parallel. Two concurrent runs racing for the next number is exactly the failure the law is written against.
- Draw the number with a conditional update that returns it, not with
max(number) + 1, which two simultaneous readers both read as the same value. - Put a unique index on account and number as the net underneath. If the counter is ever wrong, the insert fails instead of issuing the same number twice.
A preview draws no number. The sequence belongs to documents that go into the books, and one sequence per calendar year matches what everyone expects, with the year boundary being the only moment a jump in the series alarms nobody.
The cycle, corrected
- Wait for the cut-off. A running period has no document. Deliveries accumulate, the draft is computed on demand and changes freely as leads are returned.
- Check the gaps first. Missing name, address or country on a partner is reported before the run, not discovered inside it.
- Run. Count the unbilled deliveries in the period, apply each agreement's price, determine the tax case, draw the number, produce the document and the electronic format.
- Send. Email with the document, and in the buyer's portal at the same time, so the count they check is the count you billed.
- Track. Open, overdue, paid, cancelled. Returns after this point become credit notes; late deliveries become supplements.
Count the reminders, record when the last one went out, and leave the decision to send the next one to a person. When you chase depends on the relationship, and the relationship is not in the database: an automation sends the second reminder to the buyer you were on the phone with yesterday. This is the one step in the cycle worth not automating.
| Document | Partner | Period | State | Amount |
|---|---|---|---|---|
| 2026-0184 | Nordkontor Vertrieb GmbH | 52 × 40 € | paid | 2.080,00 € |
| 2026-0185 | Rheinwerk Süd GmbH | 31 × 120 € | open | 3.720,00 € |
| 2026-0186 | Vialux Solar B.V. | 44 × 95 € | overdue | 4.180,00 € |
| preview | Alpsol Handels GmbH | 61 × 250 € | preview | 15.250,00 € |
A preview still changes. An invoice carries a number and does not.
What we do and do not do
Ours, so read it as a worked example. Invoicing here is part of the distribution module rather than a separate tool: the deliveries being billed are the same rows the routing engine wrote, so there is nothing to export and nothing to reconcile. Monthly or weekly cadence, drafts computed rather than stored, gapless numbering per year, the four tax cases with the case stored on the document, ZUGFeRD and XRechnung with a visible status, credit notes, supplements, and the buyer's own portal showing the same deliveries the invoice counts.
Not present, so you can plan around it: no volume-tier pricing, as above. No partial payments, so an invoice is open, overdue, paid or cancelled and a part payment has to be recorded outside the system. No automatic dunning, which is deliberate rather than pending. And no general ledger: this produces correct outgoing invoices, it is not accounting software, and it does not replace your tax adviser's system.
Related guides
- How to manage lead buyers and partners: agreements, rights, portals and returns.
- How to build a lead distribution system: routing, caps, delivery and the decision log the invoice rests on.
- Lead distribution pricing models: what your platform charges you, as opposed to what you charge buyers.
- Best lead distribution platforms: seven platforms with published prices only.
How this page was written
The rules in this guide are read off our own billing module and the decisions recorded with it, which is why each one is stated with the failure it prevents rather than as a feature. Two claims from the earlier version are gone rather than softened: tiered pricing by volume, which we do not support, and automatic payment reminders, which we deliberately do not send. A third, partially paid invoices, was listed as a tracked state and is not one.
The tax and numbering requirements cited here are German and EU rules as they applied on 26 September 2026. They are not tax advice, and the case that applies to your business is a question for your adviser.
If something here is out of date or wrong, tell us and we will correct it.