If you run a group, the billing rule is simple: one ledger line per successful checkout, tied to the member who got it, with the amount they owe and whether they have paid. Not one message per drop. Not a running tally in your head. One line per hit, kept in the same place as the checkout record it came from. Everything below is why that shape, and what goes wrong with every other shape.

The problem is not the money, it is the recall

Billing a group is rarely hard maths. It is 10 or 20 quid a hit, sometimes a cut of the flip. The hard part is remembering, three days later, who actually got what.

Here is the shape of a normal drop. Twenty tasks fire across a dozen profiles. Nine cook. Some of those profiles belong to you, some belong to members, and two belong to a member who changed their Discord name last week. The success webhooks land in a channel, everyone celebrates, and the drop ends.

Now bill for it. You need to know which of those nine were members, which member each profile belongs to, what the agreed rate was, and who has already sent money. By the time you sit down to work it out, the webhooks have scrolled, the profile names mean nothing on their own, and you are reconstructing the drop from memory and screenshots.

What actually happens next is one of two things. You undercharge, because you only bill the hits you can clearly remember. Or you send a message asking people to tell you what they got, which means you are now trusting the person paying to report their own bill.

What a billing record needs on it

Each field earns its place. If it would not change a decision or settle a dispute, leave it off.

The checkout itself. Product, site, price, timestamp. This is what the member is being billed for, so it has to be attached to the bill, not sitting in a different system. When someone says "I never got that one", you want the actual checkout record in front of you, not a line in a spreadsheet that says "Alpha2, £10".
The profile. Profiles are how the checkout arrives. Names, rates and payment status are all attached to people, but the raw event only knows a profile. That mapping is the whole job.
The member. The person who owes. Worth storing their numeric Discord ID alongside the name, because names change and IDs do not. A rename should never orphan three months of billing history.
The amount. Fill it in when you know it. A flat per-checkout fee can be set immediately, a percentage of the flip has to wait until the item sells. Both are normal, so the ledger needs to cope with an amount that is not decided yet rather than forcing you to put a number in.
Status: owed or paid. Two states, nothing clever. The moment you add "partially paid", "promised", "will pay Friday", the ledger stops being scannable.
Whether it has been counted as income. Money that landed is income. If your ledger does not track what you have already filed, you will either double count it or forget it entirely at tax time.

Group the profiles once, not every drop

This is the single change that makes group billing bearable.

Do not map profiles to members drop by drop. Map them once. A member gives you three profile names, you group all three under their name, and from then on every checkout on those profiles bills to them automatically. New drop, no admin. When they add a fourth profile, you add it once and you are done again.

Without that, you are doing the same reconciliation work every single release, and you are doing it under time pressure while trying to run the next drop.

Why a spreadsheet struggles here

Spreadsheets are fine at holding the ledger. They are bad at the two things either side of it.

Getting data in means transcribing webhooks by hand after the drop. You will do it for the first few, then you will skip one, and a ledger with a gap in it is a ledger you no longer trust when someone disputes a line.

Getting money out means the paid rows just sit there. They are revenue, and revenue belongs in your books. So there is a second manual step, moving totals into whatever you use for income, and that step is the one everybody skips.

There is also the awkward social bit. When a member queries a charge, "the spreadsheet says so" is a weak answer. "Here is the checkout, the profile, the timestamp and the price" ends the conversation.

How we do it in Reseller OS

The Checkouts panel already captures your bots' webhooks. PAS is an optional tab layered on top of that, for people who run groups.

You track a successful checkout and it becomes a ledger line for whoever owns that profile. Group a member's profiles under their name once, with their Discord ID stored so a rename does not lose them, and future hits file themselves. Fill in the amount when you know it, or leave it blank until the flip lands, and the header tells you how many are still without a figure so nothing quietly goes unbilled.

Mark lines paid as the money arrives. When a batch is settled, one confirm files it into your Income page as a single record, so group revenue lands in the same books as everything else instead of living in a tab you have to remember. Any member's ledger exports as a CSV if you invoice properly.

The important part is what it does not do. The ledger sits on top of your checkouts. Tracking one never edits the feed, the drops, or a single order in your app. It is a layer, not a rewrite, and the tab stays hidden entirely unless you turn it on.

Want it? Join the waitlist. Free through the beta, spot in the Discord included.

The habit

Track the hit while the drop is still fresh, group each member's profiles once, and settle in batches rather than chasing individuals. Do that and group billing stops being the admin job you dread on Monday and turns into two clicks on Saturday.