AR-AP Adversarial Float

The puzzle: everything else got upgraded

Eric Glyman laid out a forty-year puzzle on John Collison's Cheeky Pint: why does business bill payment, a vendor emailing a PDF invoice with bank account details that a customer then pays, stay antiquated when nearly every adjacent rail was upgraded in place?¹ Credit cards went from no real-time authorization, to a carbon-copy imprinter, to call-up authorization, to the modem, to modern real-time networks. Checks were physically flown around the country to settle until the Check 21 Act let a scan count as the instrument, letting banks digitize and shred paper, and eventually letting a customer photograph a check with a phone. Both rails are, in Glyman's phrase, old-timey but meaningfully upgraded in place. The loose network of businesses paying each other by PDF invoice resisted that kind of in-place upgrade. Current bill-pay products, in his description, are lipstick on a pig: they scan the PDF and check that the digits were not mistyped, layered over an antiquated core.

Why it resists: accounts receivable and accounts payable are adversarial

The resistance is not primarily technical. Different accounting treatments do make spend decisions genuinely more nuanced, since a five-year depreciating asset and a pay-as-you-go software subscription are not the same kind of expense, but the deeper reason is incentive structure. Glyman states it plainly: "what do you want to do as a controller? Pay as late as possible and collect as early as possible." Float, meaning delay, is therefore a feature for one party rather than a bug to be engineered away.¹

This is also why checks persist. The difficulty of sending one is a feature, not a bug, in the same way that the friction of cancelling a gym membership is a feature for the gym: no money leaves without a signed, mailed check. At a high enough interest rate, paying by slow mailed check is both legally sound and cheaper for the payer, who keeps the float. An adversarial structure where a better rail serves no single party's interest does not get adopted on its own.

Glyman separates this from pure dead-weight loss. Fat-fingering a bank account, or falling for a spear-phishing email that redirects a payment, benefits no one except the attacker. Those frictions should be engineered away even where float cannot be.

The fixes Glyman proposes

He offers two. The first is a clearinghouse he calls DNS for companies: instead of a vendor emailing bank details that a fraudster can intercept or spoof, a payer looks the counterparty up in a central registry, confirming they are paying the real party and eliminating both spear-phishing and fat-finger errors.

The second is what he calls the Google hundred-year-bond insight: if Google owes a supplier money, Google's incentive is to pay as late as possible, and Google can borrow for roughly a hundred years at around three percent, close to Treasury rates plus a small spread. A small supplier, by contrast, borrows at eighteen to twenty percent. Glyman's point is that a supplier's own receivable is functionally its large counterparty's payable: "my AR is their AP." A supplier should be able to borrow against a Google receivable near Google's own cost of capital rather than at what Glyman calls its own "little schmuck" rate, and the only way to unlock that is more data connecting the two sides together.¹

Why it matters

The framing explains a structural gap that fintech is moving into, since bill pay combined with software spend is already a business worth well over a hundred million dollars in annual revenue at Ramp,¹ and it clarifies that the prize is data and connection between counterparties, not simply a prettier interface. It also connects working-capital strategy to two adjacent, positive-sum moves: collecting before paying compresses a negative cash conversion cycle, and financing a receivable at the counterparty's rate is a concrete instance of embedded lending built on top of that same connected data.

Open questions

A DNS-for-companies clearinghouse needs something close to universal adoption to work at all, the same chicken-and-egg problem that any shared standard faces, and it is the same network problem that has kept PDF invoices alive for decades. Borrowing at a counterparty's rate also requires that counterparty, or some neutral party, to vouch for the receivable, and who underwrites that vouching and who bears the default risk remains unsolved.