Guides
How to invoice your reseller customers
What a reseller invoice must show, invoicing each sale versus running one bill a month, keeping wholesale cost off the page, and chasing what is overdue.
The short answer
To invoice a reseller customer, list what they bought, when payment is due and any tax, then send it and collect the money the way you already do: a reseller platform keeps the record, it does not move the money. Invoice a sale as it happens if customers buy occasionally, or run one monthly billing run that bills everyone's uninvoiced sales in a single pass if you have many small, recurring customers. Keep the wholesale price you paid separate from the price you charge, which should come from a price list rather than the order itself. An invoice is overdue from the day after its due date, so track those separately and chase them by customer, not one invoice at a time.
To invoice a reseller customer, list what they bought, when payment is due and any tax, then send it and collect the money the way you already do. Invoice a sale as it happens if your customers buy occasionally, or run one monthly bill that invoices every customer's uninvoiced sales at once if you have many small, recurring ones. Keep the wholesale price you paid separate from the price on the invoice, and track overdue invoices by customer rather than one at a time.
The rest of this guide goes through each of those decisions, and what they look like built into a product rather than done by hand.
What must a reseller invoice legally show?
It depends on where your business is, and the two major jurisdictions most resellers deal with do not agree line for line.
In the UK, gov.uk's own guidance says an invoice must include:
- A unique identification number
- Your company name, address and contact information
- The name and address of the customer you are charging
- A clear description of what you are charging for
- The date the goods or service were provided
- The date of the invoice itself
- The amount or amounts being charged
- The VAT amount, if you charge VAT
- The total amount owed
(GOV.UK: Invoices - what they must include, read 11 October 2026.) VAT-registered UK businesses have to add further detail beyond this basic list, and sole traders and limited companies each have their own extra requirements for the name on the invoice.
The US sets no equivalent federal list. The IRS's own recordkeeping guidance says a business "may choose any recordkeeping system suited to your business that clearly shows your income and expenses," and that "except in a few cases, the law does not require any special kind of records" (IRS: Recordkeeping, read 11 October 2026). What an invoice has to show there is mostly a matter of your state's sales-tax rules and your own accounting practice, not one federal standard. If you invoice into other countries, check their own rules too rather than assume either of these applies.
Whatever the country, the same five things show up on almost any invoice that holds up: who is billing, who is being billed, what was sold, when payment is due, and how much is owed before and after tax. That is the shape the rest of this guide, and ResellerHQ's own invoices, are built around.
Should you invoice every sale, or run one bill a month?
Which to choose comes down to how your customers buy.
Invoice as you go when a customer buys a handful of things occasionally: one domain renewal, a seat added mid-month, a number rented for a project. Waiting for a cycle just delays getting paid for something that already happened. This also suits a customer who expects to be billed the moment something is delivered.
Run one bill a month when you have a roster of customers who each buy small things through the month, and you would rather send thirty invoices on one day than dozens scattered across it. A monthly run bills every customer's uninvoiced sales for the period in a single pass, instead of you opening each customer in turn.
The two are not mutually exclusive. You can invoice a customer the moment they buy something unusually large, and still catch everyone else's routine purchases in the next monthly run: an invoice only ever bills sales that have not already been invoiced, so nothing is billed twice whichever way it is raised.
How does a monthly billing run work?
A billing run is two steps, and nothing is billed until the second one.
- Preview. You set a cut-off date, and the run works out one row per customer and currency, covering every sale made on or before that cut-off that has not yet been invoiced. Nothing is written yet: this is a computation, not a commitment, so you can look at it, see what it would bill, and change your mind.
- Commit. Raising the invoices for every row you have not excluded by hand. This runs in the background, so you watch its progress rather than wait for a single request to finish.
A row can be excluded before you commit, which holds that one customer back from this run without affecting anyone else's. If a row fails during commit, for instance because something about that customer's sales changed in between, the run is marked as completed with failures, and committing it again retries only the rows still failed, leaving everything that already succeeded untouched. That makes it safe to simply try again rather than work out by hand what went wrong.
One run holds a large but finite number of rows. If more customers are waiting than that, the run tells you it was truncated, bills the ones it could reach, and the rest come up in your next run.
For the per-sale route this sits alongside, see the price lists that decide what each sale is billed at before it ever reaches an invoice.
How do you keep what you paid wholesale separate from what you charge?
The two numbers should never be the same column on the same page, and the way to guarantee that is to let them come from different places.
What you pay upstream is wholesale cost, taken from your prepaid wallet the moment an order is filled; see prepaid wallet billing for resellers for how that side of it is held, captured and released. What a customer pays is a different figure entirely, set by a price list: a markup over wholesale for everything on that list by default, with exceptions for a price fixed on one item, a contract agreed with that customer, or the price they paid last time on a renewal. Every sale records both figures, so you can see your margin on it without doing the subtraction by hand yourself.
An invoice should be built from the customer-facing side of that sale, never from the wallet transaction. Get that wiring backwards even once, and a customer ends up billed your cost rather than your price. If you are still deciding how to price domains and email seats in the first place, how to price what you resell goes through markup, price lists and customer-specific rates, and how to start a domain and email reselling business covers where the margin actually sits.
How do you chase an overdue invoice?
An invoice is overdue from the day after its due date, not on the due date itself, so one due today still has the whole day left before it counts as late. That one-day grace matters when you are deciding whether to send a reminder: a customer billed to pay by the 15th has not missed anything on the 15th.
Beyond that, chasing is mostly a matter of what you look at first. A list of every open invoice, sorted newest first, is the wrong view for collections: it buries the invoice that has been outstanding for two months under the one raised an hour ago. What you want instead is to narrow that same list down to the overdue ones alone, with a count beside them so you know how big today's job is, and to read it oldest first: the invoice that has been outstanding longest is the one worth a phone call, and a customer who turns up on that list three times is one conversation rather than three.
It also helps to separate "open" from "overdue" as two different numbers rather than one. Open includes everything still waiting to be paid, whether or not it has fallen behind; overdue is the part of that which has actually missed its due date. Watching the two side by side, per currency if you bill in more than one, tells you whether your open balance is healthy cash-in-progress or a growing collections problem.
How do you mark an invoice paid, or undo one?
Marking an invoice paid is a record, not a transaction: nothing is charged by doing it, because the money already moved somewhere else, by whatever method you actually collect payment. You are telling your own books that it arrived, optionally backdated to when it actually did, which matters if there is a gap between the money landing and you getting round to recording it.
Undoing an invoice is different from marking it paid, and the two should not be confused. Voiding an invoice withdraws it: its number is retired for good so it is never reused, and the sales that were on it go back to being uninvoiced, which means they can be put on a different invoice afterwards. A paid invoice cannot be voided, which keeps the rule simple: once money has actually arrived against an invoice, the record of it should stay rather than be unwound.
If you ever bill a customer twice for the same thing by mistake, usually because a request was retried after a timeout, the fix is to make sure a retried request cannot create a second invoice in the first place, rather than to rely on catching the duplicate afterwards and voiding it. Idempotency keys and webhooks for reseller APIs goes through how a key does that, and how to react to the result without polling.
What does invoicing look like in ResellerHQ today?
ResellerHQ's invoicing follows the shape above, built around a simple rule: it keeps the record, it never moves the money.
Billing a customer works either of the two ways this guide describes. Billing one customer for everything they have bought and not yet been invoiced for, or for a list of sales you pick yourself, raises a single invoice in one currency, copying each sale's price into a line exactly as it stood at the time of the sale, up to five hundred sales on one invoice, oldest first. Sending a request with an idempotency key means a retried request can never create a second invoice for the same thing. Running a monthly bill works the preview-then-commit way described above, across every customer with uninvoiced sales at once, with rows you can exclude and a commit you can safely retry if some of it fails.
Who the invoice is from is your own business details: a legal name, an address, a tax or VAT number and a billing email, filled in once and then shown in the From block of every invoice you raise afterwards. An invoice raised before any of that is filled in shows only your account name, and the dashboard says so, with a direct way to add the rest. What a new invoice starts with, due in how many days, what tax rate, what note at the bottom, is set once as an account default and then applies to every invoice unless you change it on that one; an explicit value you type always wins over the default, including an explicit zero or a blank note.
Marking an invoice paid or voiding it works exactly as described above, with nothing charged either way. An invoice can also be turned into a public, read-only link that needs no login to view: handing a customer that link, rather than a PDF, means they are always looking at the current state of the invoice, and revoking the link kills it immediately. The same printable sheet is drawn wherever the invoice is read, your own dashboard or that public link, so there is no second version to keep in sync. Three events, invoice.created, invoice.paid and invoice.voided, fire as webhooks so your own accounting or notification system can react without polling; see the webhooks guide for how to subscribe to them.
What ResellerHQ does not do is take the payment itself. There is no card form on an invoice and no payment processor behind the "mark as paid" button: you collect the money however you already do, by bank transfer, card terminal or anything else, and ResellerHQ's part is keeping an accurate, shareable record of what was owed, by whom, and whether it has been settled.
Questions
- It depends on the country, so check the one you are billing from rather than copy a template. In the UK, gov.uk's guidance says an invoice must show a unique invoice number, your name and address, the customer's name and address, a description of what is being charged for, the date the goods or service were supplied, the invoice date, the amount charged, the VAT amount if you charge VAT, and the total owed. In the US, the IRS sets no equivalent federal list: it only requires that whatever records you keep clearly show your income and expenses, so an invoice's exact content there is mostly a matter of your state's sales-tax rules and your own accounting practice.
- Invoice as you go if customers buy occasionally and you would rather be paid sooner than wait for a cycle. Run one monthly bill instead if you have a roster of customers each buying a few small things, since a single run works out every customer's uninvoiced sales in one pass instead of one invoice at a time.
- It is a two-step process. Previewing it works out one row per customer and currency, covering everything they bought that is not yet invoiced, without writing anything yet. Committing it then raises the invoices for the rows you have not excluded by hand, and if some rows fail you can commit the same run again and only the failed rows are retried.
- Set what a customer pays on a price list, with a markup over wholesale or a fixed price for particular items, and let each sale carry both figures: the wholesale cost charged to your wallet, and the customer-facing price your price list set. An invoice's lines copy the customer-facing price recorded on the sale, never the wallet transaction, so the two numbers are never mixed on the page your customer sees.
- An invoice becomes overdue the day after its due date, not on the due date itself, so one due today is not yet late. An open invoice can be voided, which withdraws it, frees its sales to be put on a new invoice, and never reuses its number, but a paid invoice cannot be voided.
- No. Every invoicing feature in ResellerHQ keeps a record only: you take payment from your customer however you already do, by card, bank transfer or anything else, then mark the invoice paid yourself so the record matches what actually happened.
Sources
- GOV.UK: Invoices - what they must include gov.uk
- IRS: Recordkeeping irs.gov