Billing Operations

With ten customers this work needed no name. One spreadsheet held the company name, the amount and the billing date, and once a month somebody read down the rows and sent the emails. Nobody reached for a calculator. There was one plan and everyone paid on the same day.

Columns multiplied as customers arrived. Some teams paid monthly, others annually. One team added three seats in the middle of May. Another team's card, registered in March, expired in August. An enterprise buyer insisted on paying by bank transfer and asked for tax paperwork before their finance team would release anything. Every new column was another place to be wrong.

The trouble shows up at the end-of-month meeting. Sales reports 200 million won in signed contracts, the bank account shows 140 million won received, and nobody can account for the gap on the spot. Picked apart later, it turns out seven contracts were never invoiced at all, twenty customers had been sitting on a failed card charge for two months, and three accounts upgraded their plan but kept getting billed at the old price. None of it is a disaster. Each item is a few hundred thousand won, but the same leaks reopen every month, and together they come to a few percent of revenue. The gap was never one mistake somebody could have caught in the meeting. It was thirty small ones spread across three systems that nobody had reason to read side by side.

Billing operations is the work split off to plug those leaks one at a time. It starts from the assumption that the amount sold and the amount collected do not match on their own, breaks the steps between them into named parts, and gives each part an owner and a moment. Once a step has a name you can point at the leak, and once you can point at it you can decide who watches it.

The work underneath splits four ways: what justifies the charge (documents), how the money actually travels (rails), how a mid-cycle change turns into an amount (calculation), and what happens when the money does not show up (collection).

The order matters as much as the list. Each part hands something to the next one, so a gap anywhere along the chain eventually shows up as cash that never arrived.

Documents create the paper trail behind a charge. There are two of them, and they divide by who receives them, the customer or the tax authority.

1. Invoice — the bill sent to the customer. It lists which plan, how many seats, over what period, and therefore how much, line by line. This is the file a buyer attaches to an internal approval request, so vague line items stall that approval and push payment back by however long it sits there.
2. Tax invoice — the statutory record used when filing value-added tax (VAT). A copy goes to the tax office, so the format and the deadline are set by law. In Korea it has to be issued by the tenth of the month after the month of service, and missing that date adds a penalty.

The two names look alike; the jobs do not. An invoice asks the customer for money. A tax invoice tells the government a transaction happened. Send the invoice and forget the tax invoice and the cash arrives but the next filing catches you. Issue the tax invoice without the invoice and the buyer's finance team has nothing to approve against, so payment stops.

Rails cover the path the money travels. A payment gateway is an outside service that stores card details on your behalf and passes charge requests to the card networks. Companies avoid holding card numbers themselves because storing them drags heavy security obligations along. The trade is a fee. Card payments in Korea usually cost two to three percent of the charge, so a company collecting 50 million won a month on cards gives up roughly a million won of it. Enterprise buyers with large contracts prefer bank transfers for the same reason: the fee scales with the size of the deal.

Two rails also means two ways of checking. A card clears or fails on the spot, and the failures land in a list right away. A bank transfer announces neither success nor failure. On the promised date somebody opens the bank statement and walks it line by line against the list of open bills to learn what did not arrive. That is why two companies with the same customer count need very different amounts of human attention when one of them collects mostly by transfer.

Calculation handles customers whose terms changed partway through a cycle. Proration prices the days on each side of the change separately. A team on a 100,000-won plan that upgrades to a 200,000-won plan on the fifteenth owes 150,000 won that month rather than 200,000: the first half at the old price, the second half at the new one. Done by hand this produces dozens of cases a month, and a single wrong one is the kind of error a customer spots before you do, so the rule usually lives in the system. The same rule runs in reverse when a team drops seats or downgrades, and there the open question is whether the unused portion comes back as cash or as credit against the next bill. Choosing one and writing it down matters more than which one gets chosen, because support fields that question several times a week.

Collection deals with money that did not arrive on schedule. There are four cases, and the response depends on why the money stopped.

1. Dunning — retrying a failed card charge on a schedule and telling the customer about it. More than half of failures come from a temporary cause such as a spending limit or an expired card, so three attempts spaced out over two weeks, say on day three, day seven and day fourteen, recover a large share of them.
2. Refund — money the company hands back on its own initiative. It splits into cases that are the company's fault, such as a duplicate charge or a wrong amount, and cases where the customer asks and policy allows it. Without a written rule on how long and how much, every request gets a slightly different answer.
3. Chargeback — the customer disputes the charge with the card issuer and the payment is reversed. The outcome resembles a refund but the procedure runs backwards: the issuer decides, and the company is the side submitting evidence that the charge was legitimate. Past a certain rate the gateway raises its fees or drops the account entirely.
4. Accounts receivable — billed money that has not landed yet. It piles up with enterprise customers paying by transfer. Teams bucket it by how late it is, usually 30, 60 and 90 days, and chase anything past 90 days together with sales.

The four parts run in a line. Documents create the basis for the charge, rails turn that amount into money, calculation keeps the amount honest when terms change, and collection goes after whatever still did not arrive. Slack at the front makes work at the back. A muddy line item delays a buyer's approval by a week and receivables age by exactly that week; a proration error that overcharges someone comes back not as a failed payment but as a chargeback.

"This account upgraded on May 15, so the prorated charge this month is 150,000 won."

Confirming that a mid-cycle change means the full month cannot be billed as is.

"Thirty-two charges failed last month and retries recovered nineteen of them."

Reporting what the automatic retries brought back, and flagging that the remaining thirteen need a person.

"They need the tax invoice first, otherwise the approval on their side cannot move."

Not a nudge about money. The other side simply has no document to route for approval yet.

At Pagedeck billing goes out in one batch on the first of the month. Upgrades from the free plan and seat increases are applied first, then the amounts for anyone who switched plans get split by date. Card accounts are charged that day, and enterprise accounts paying by transfer receive the bill and the tax paperwork together. For three days after the run Mia defers any plan change request to the following month, because two recalculations in one cycle leave the customer holding a bill that does not match what left their account.

The problems surface the week after. Last month forty teams turned out to have been using the product for more than ten days on a failed charge. Grace did not ask about the amount, she asked why nobody noticed, and the answer was that failure notifications were arriving in a mailbox nobody opened. Anything still unrecovered after two days now lands on Sofia's list automatically.

Enterprise contracts add a second pass. The accounts Sofia handles pay on terms rather than by card, so their bills leave on the first while the money is only expected up to thirty days later. Until then those amounts sit in the open list, and closing the month means separating what is genuinely late from what is simply not due yet.

The most common reading is that this is routine clerical work: build the bill, send it, tick off the payment, repeat. It looks that way because the same shape comes around every month. In practice every change to the billing model, the structure that decides what you charge for and how much, creates fresh design work here. Add usage-based pricing and three new questions appear at once: where usage gets counted, when a customer who passes a threshold mid-month is charged, and how that line reads on the bill. Treat the work as clerical and it starts only after the pricing decision is final, by which point a launch date already exists. Announcing a new plan and getting the billing for it two months later usually begins here. Scale changes the shape as well. Ten customers fit in a spreadsheet, a hundred need a schedule and a checklist, and a thousand need the rules written into software, because past that size no single person can read every row before the batch goes out.

The other common belief is that the leaks are small enough to clean up later. One item is a few tens of thousands of won, so nothing feels urgent. The catch is that this loss is not a one-off; it reopens in the same place every month. Leave failed payments alone at two percent a month and a year later a quarter of your customers are using the product without paying for it. The damage is not only cash, either. A loose billing process reports revenue lower than it really is, and that understated number becomes the basis for a fundraising conversation or a pricing decision.