A return is not revenue, and an advance never was

Two files, same merchant, same month. In the first, revenue is the total of everything that arrived in the account. In the second, it is what the business actually earned from its customers. The financing payments are identical in both. The burden percentage is not, and the gap between them is routinely the difference between a file that gets funded and one that does not.

The error has a direction, which is what makes it worth writing about. Money that lands without being earned nearly always makes the picture look better: the denominator grows, the ratio falls, the merchant appears to have room. Nobody has to be deceived for this to happen. It is the default behaviour of counting deposits.

The returned payment deserves the closest look, because it is the only one that damages both sides of the ratio at once. A $1,450 pull leaves on the 29th. On the 2nd, $1,450 comes back as a returned item. Left unpaired, the merchant is credited with $1,450 of revenue they did not earn and debited with $1,450 of financing they did not ultimately pay.

So the two are paired: a return-like credit is matched to a position debit one-to-one, by exact amount, to the cent, inside a window of a few banking days. The matching is deliberately narrow. Only debits already identified as position payments are candidates. One return credit can consume at most one debit, because two identical pulls from two different funders cannot both have been reversed by a single line. Amounts are compared in whole cents so floating-point drift cannot break a match that is exact.

What follows from the pair is the part worth arguing about. The credit is never revenue and the debit is out of the payment total — the two net to zero, which is what actually happened. But the detection cadence and the estimated monthly obligation still count the attempted pull, because the contract did not shrink when the payment failed. A funder still expects that money. A bounced payment is a sign of strain, not of relief, and a report that quietly reduced the obligation would be reading it exactly backwards.

Both lines stay in the transaction list, linked to each other, with the returned item keeping its own tag. The pairing changes what the rows mean to the arithmetic, not whether you can see them.

It is tempting to treat exclusion as prudence: strip anything that might not be revenue and the burden figure errs on the cautious side. That is its own error, and it lands on merchants who did nothing wrong. A deflated denominator reports heavy burden on a business that is comfortable, and a file declined on a number that was never real is a loss nobody sees.

So several rules exist specifically to protect real revenue from a careless exclusion. Takings that reach the merchant through a funder sitting between them and their card acquirer are the merchant’s money and are counted as revenue, whatever name is on the credit. A marketplace payout stays revenue even when the bank labelled the line a transfer, because who paid outranks what the descriptor called it. And a customer whose company name happens to contain a word like “salary” or “capital” is not dropped from the revenue base over a substring — an explicit read of the line beats a keyword every time.

One case is neither included nor silently dropped. Personal payment apps are excluded by policy, since most of that traffic is not trade — but plenty of small merchants genuinely are paid that way, so the excluded total is surfaced rather than quietly removed. You can see what was set aside and decide whether it belongs.

When a report shows revenue below the deposit total, the difference should be explainable line by line rather than taken on faith. Every excluded credit is still in the transaction list, carrying the tag that explains why it sits outside the revenue base: an advance, a return, a transfer, wages. If a single large credit accounts for most of the gap, it is worth two minutes of your attention before anything else in the file is.

And when the classification is wrong — a genuine customer read as a funder, a transfer that was really a sale — correcting the tag and recalculating re-derives everything downstream: revenue, burden, positions, the risk summary. Not a patched number in one panel, the whole analysis again from the corrected rows. The judgement about what the money was belongs to the underwriter. The arithmetic that follows from it should never have to be done twice by hand.