Build vs. Buy for Billing: Who Finds Out When You're Wrong?

Build vs. buy for billing used to settle itself. Someone would estimate the build at a quarter of a senior engineer's time, someone else would look at a vendor's pricing page, and the scarcity of that engineer made the decision for you. The estimate did the prioritizing.

That estimate is now a couple of weeks, powered by AI. A working entitlements service, a usage meter, or a credit ledger really does come together in days. Building got cheap enough that the old build vs. buy decision is back on the table, and a lot of teams are looking at their billing stack and thinking, "we could just build this".

You can build a working billing system. The problem is that "how long to build" was never the most important issue. What's most important is:

For internal tools, build in-house! A support triage bot, the customer view your AEs want, and the CPQ that started as a spreadsheet are all great targets. When one of these is wrong, the person who finds out is the person using it, they find out immediately, and the damage is an annoyed coworker and a Slack message. The system corrects itself quickly and the harm is minimal.

That's the class of software worth building in-house, and it got a lot more worth it in the last two years. It's specific to your company, the requirements change with your process, and the cost of being wrong is small and visible. Build it, iterate on it, don't feel bad about the vendor you didn't buy.

Billing, entitlements, and metering come back from the same three questions with the worst possible answers. Someone other than you finds out, they find out much later (often several months later), and the damage is measured in revenue and customer trust.

Below are the top four ways we see it go wrong. It's worth noticing up front that these aren't code-quality problems, they're "we built the wrong thing" problems. The real cost of building it yourself, is having to learn each lesson, one deal or one month close at a time, with an engineer pulled off roadmap work each time to fix it.

Revenue you never billed. The most common way a homegrown billing stack loses money is also the quietest one. A customer buys something, the feature gets turned on, but their bill never changes. The customer is the only one to notice the issue, and they have no reason to flag it.

One VP of Finance at a vertical SaaS company with about 3,500 accounts found his by hand. He reconciled every account line by line, and turned up a handful of deals where a feature had been switched on and billing never followed. The biggest was a customer who'd been upsold a second feature a year and a half earlier. $4,000 a month for thirteen months, $52,000 total, was never billed. "We have no recourse to go back to the customer and say you owe us $52,000. They're going to say, you messed up, you eat that."

Customers you churned. Billing mistakes cost you trust, and it barely matters what the mistake was. Once a customer has caught their vendor getting the bill wrong, every invoice after that gets read line by line. The upcoming renewal that should have been a formality becomes a live sales process.

A large public SaaS company launched usage-based pricing on a billing system built for seats. Mid-term usage purchases were prorated one way, seats a different way, and nobody was clear what the final renewal number should be. Sales explained it deal by deal, but trust eroded anyway. Churn went up 24% and took three quarters to come back down.

Deals you slowed down or lost. The billing system's limits are often discovered by sales, mid-deal, when a prospect asks for something it can't do. At that point the answer is no or wait. No shrinks the deal to whatever the system can already do. Wait sends it back to procurement, where a champion who thought they were done has to start defending you again.

A head of product at a software roll-up learned about one in a leadership meeting the day after it happened. A customer bought one product and was about to buy a second, deeply integrated one. The company sent two invoices, because the two products lived in two billing systems. "They were like, what do you mean? I thought you own both of these. ... And they said, oh, we'll get to [the second one] later." Half the deal got deferred indefinitely because the bill came in two pieces.

Close of books. Finance is the last to know, by design. As one VP of Finance put it, "our work starts when the month is over," so every billing anomaly is at least a month old by the time finance even has the data to catch it.

A design tool ran on credits. Every plan included a monthly grant, customers bought top-ups, marketing ran promotions that dropped credits into new accounts, and support had a button to grant credits when something broke. Engineering built one ledger for all of it and none of it tracked usage how accounting needed it. At year end the auditor asked how credit revenue was recognized. Purchased credits are deferred revenue until consumed. Plan grants are subscription revenue over the term. Promotional and support grants aren't revenue at all. The audit stalled while finance and engineering rebuilt two years of consumption from application logs.

Every failure above was expensive, and every one of them is avoidable, because every one of them had already happened to someone else. That's what a vendor actually sells. Not the code, which takes a week, but the mistakes already made and the team whose sole focus is preventing them. When your pricing changes next year, that team makes sure the system is ready for it, instead of an engineer you pulled off the roadmap.

That's what Schematic is. Plans, versioning, features, entitlements, usage limits, and credits in one model your application checks against at runtime. What a customer is entitled to and what they're billed for come from the same record. Seats and usage live together instead of in separate systems. The cross-sell is one subscription, not two invoices. Every credit grant and every unit consumed is on the record with its source when finance asks. We're not smarter than your team. We've just already made and fixed these mistakes.

Before your next build vs. buy meeting, take the thing you're about to build and answer the three questions honestly. When it's wrong, who finds out? If the answer is a customer or prospect, you're looking at a different class of system than the one your team just built for support. When do they find out? If the answer is "on an invoice" or "at renewal" or "at close," the bug has already become a trust problem before it's a ticket. How much has it cost by then? If you can't put a number on it, that's because the number is revenue.

Internal tools fail loud and cheap. Build those, and build more of them than you used to. Billing, entitlements, and metering fail quiet and expensive, and the quiet is what makes them expensive. That's the layer Schematic exists for. It's also the one place where "we could build this in a couple of weeks" is completely true and still the wrong reason to do it.