Apurv Bansal

The through-line

Bansal's whole argument starts from one observation he made inside Google: even a company of that size was building its own billing plumbing. "There was like an army of engineers who were devoted to automating these processes by building in-house tooling" [4], and it was not by choice. "It's not like they wanted to build it inhouse. just could not find a way to solve that problem" [3]. His co-founder Sorab had built in-house billing systems at two previous startups and could not find a tool that fit [2][3]. The conclusion they drew, and the one everything else follows from, is that the billing tools on the market were designed for a pricing model the industry is leaving behind: "all the billing tools in the market were built keeping subscription billing in mind because subscription billing used to be the main pricing model like a decade and a half ago" [3].

The consequence he keeps returning to is that pricing complexity is not a finance problem that finance created. It comes from sales people crafting creative deals and from products metered by consumption, and it lands on the finance team as manual work. "Sales people typically go sell creative deals to customers and finance teams are left to kind of figure out how to take those sales contracts and convert them into invoices and revenue" [4]. Over time his framing has widened from "billing automation for software companies" [1] to a full order-to-cash platform covering billing, collections, revenue recognition and SaaS metrics reporting, with a CPQ module coming [2], and from software as the only target to any B2B business with a SaaS-like or metered pricing model [2].

On why usage-based pricing breaks the finance stack

His clearest explanation is structural. Under seat pricing, everything the finance team needs is in the contract: "you bought a 100 seats at $200 per seat... The price is in the contract. The quantity is in the contract" [3]. Move to consumption and the quantity disappears from the contract, because neither party knows it yet. "The contract only has the pricing. It does not have the quantity and the quantity in this case is the usage... and that information resides outside the contract" [3], living in a product database or data warehouse [3][4]. The billing system's job is to marry the two. And the contract terms themselves get creative: free tiers, tiered rates, minimum commitments, year-on-year uplifts, all differing per customer "depending upon how creative your sales team gets" [3], plus discounts, credits, rebates, ramps and milestones on any sales-led motion [2]. So the requirement is a system "flexible enough to encode all these different contractual structures that your sales team may be selling" [3].

Two things then degrade. Time to invoice stretches, because someone has to pull data from the warehouse, get engineering to send it, transpose it in Excel and marry it with pricing [3]. And errors rise, with an asymmetry he treats as the real cost: "if you're overbilling your customer, trust me, they your customer will tell you and they won't care... but if you're under your customer, they'll never tell you and you're just losing" [3]. Zenskar has repeatedly found underbilling at customers [3]. Revenue recognition compounds all of it. Subscription rev rec is straight-line over the contract term; usage-based rev rec has to be recomputed each period from a third system engineering controls, with minimum commitments trued up over the contract life, producing "all these hairy hairy edge cases" [3]. The more often you close books, the more that gap in time and error rate compounds [3].

On how a company should actually make the transition

He is unsentimental about the gap between proposing usage pricing and implementing it. The change is cross-functional before it is technical: "The CEO can't just say, 'Hey, let's move from a per se model to a usage based model'" [4]. Sales has to weigh the friction it adds or removes, product has to confirm it can even measure the chosen metric, and finance has to confirm it can recognise revenue on that basis [4]. What every company needs first is "a reliable way to know how much their consu every customer is consuming because that now ties directly into revenue. It's not just used for product analytics" [3].

On the engineering mechanics he offers two routes and a preference. The common one, which most vendors including Zenskar support, has the customer's engineers pipe usage events through the billing system's API [2][3]. The problem is bandwidth: "it's very hard for a finance team to get engineering bandwidth to implement a billing solution" [2]. So Zenskar also plugs directly into the warehouse where the data is already being logged, Snowflake, Postgres, Redshift, MongoDB, and pulls consumption out of a table, which removes the engineering dependency altogether and cuts implementation time [2][3]. He describes the platform as sitting between the CRM and the ERP: contract terms in from the CRM, journal entries and payment data out to the ERP, with the warehouse substituting when the CRM data is incomplete on a product-led motion [2], acting as "your central nervous system for the finance function" [4]. On where the pricing catalogue should live, there is no settled answer and he refuses to force one: full automation means the catalogue lives in the CPQ and flows into billing, but many customers either have no CPQ or use one for only a fraction of contracts, with the rest sitting on a PDF in a drive [3]. When the CPQ cannot express a model like a prepaid commit with post-paid overage, customers split the work, feeding the unsupported models straight into the billing tool because it is the more flexible system [3]. He is candid that this bottleneck effect is simply "a truth of how software is built" [3].

On pricing as a reflection of how customers see value

Bansal argues pricing should track the customer's value lever, not the vendor's cost lever. "It's easiest to sell to a customer if your pricing model correlates to the way they see value from the product as opposed to how what it means for you from a cost perspective" [4]. His examples are concrete: a support tool charging per resolved ticket rather than per seat, HubSpot charging on opportunities in the CRM rather than a flat monthly fee [4]. His strongest case is a telemedicine vendor that priced on video minutes, its own cost driver, while hospitals measured value in patients served. Switching the meter to patients closed more deals, because customers "saw more value in terms of number of patients and were more aligned to paying for the tool based on how they see value" [4]. Different segments perceive value differently, which means different pitches and different models per segment, and a strong negotiator will pull custom terms into the contract on top of that [4]. His conclusion is blunt: "If you're not offering that dynamic pricing, you'll just lose revenue" [4]. He has separately discussed how businesses can significantly increase revenue by adjusting pricing models [7][9], how variable and value-based pricing raises the bar for billing platform flexibility [8], and how adding AI features makes consumption, not just the model price, the hard part for billing, rev rec and business measurement, an echo of the earlier shift from perpetual licences to subscriptions [6].

On homegrown billing systems and legacy vendors

He is careful not to say Google got it wrong, only that the allocation was wrong: "the number of engineers working on that was not something that made sense. It felt like those engineers could be shipping more products" [4]. His diagnosis of why in-house systems decay has four parts. They are built by engineers who are not finance experts, who "may not know the difference between approved revenue and deferred revenue" or how prepaid versus postpaid affects cash flow [4]. They are built reactively around today's pricing model rather than what pricing might look like in five years [4]. They are not staffed with the best engineers, because those go on customer-facing features [4]. And so they work for six to twelve months and then rot as new products and pricing models arrive, absorbing more engineers to maintain something that was supposed to be a one-time build [4].

Legacy vendors fail for a related reason. They were built more than a decade ago for "plain vanilla per seat per month per user per month kind of pricing" [2] and cannot scale with a business launching new pricing models, which is precisely what forces customers back into hiring engineers [1]. That is where he places Zenskar's differentiation: catering to complex pricing rather than merely subscription [1], and handling usage natively, which he claims Zenskar does "literally better than any other vendor out there in the market" [2]. Deals arrive in three shapes, replacing Excel, replacing a legacy vendor, or replacing a homegrown system, with Excel more common at smaller companies and the other two at larger ones [2].

On who buys, and when

The trigger signals he gives CFOs are operational, not conceptual: two or three people spending fifteen to twenty days a month generating invoices; dozens of spreadsheets with hundreds of tabs and thousands of rows of revenue schedules; or tooling installed years ago that no longer keeps up, so books still take a week to close [4]. The ideal customer is a company with an in-house finance team, since that is where the need to automate billing and rev rec is critical and where a single system covering both is valued [2].

On segment, he started deliberately narrow. "In an early day it's important for startups to have focus and solve one thing really well for one type of customer," with software chosen because consumption pricing made the pain most acute there and the market is very large [1]. Expansion to offline businesses, large banks and telecommunications was always the plan [1], and by the later telling that is happening: AI and fintech companies, plus transportation, telecom and logistics firms with SaaS-like pricing [2]. On size, he expected only larger companies but found pre-revenue firms approaching because they need billing sorted before launch; the sweet spot he names is north of $10 million up to a couple of billion, below which "you still at that stage where you could you would excel and you don't really need automation" [2]. Zenskar's own pricing has moved with the product. Early on he described charging a percentage of the revenue processed through the platform, billed monthly or sometimes annually [1]; later he describes custom pricing driven by which modules are used, how many customers you are invoicing, and a qualitative read on billing complexity, so two customers with the same customer count pay differently [2].

On what CFOs should be measuring and doing

He gives two, or arguably three, metrics for a billing system. Time to invoice, because "the longer you delay it, the later you collect cash and cash flows get delayed" [4]. Accuracy, framed again through the overbilling-churns, underbilling-bleeds asymmetry [4]. And cost of billing, including man hours, tooling and the opportunity cost of a finance hire spending ten days a month on invoices instead of "budgeting and forecasting and strategy" [4].

Beyond the mechanics, he holds a strong view on the role itself. "CFOs role is not meant to be just to drive financial. CFOs have to drive strategy and bringing the financial lens to driving strategy" [4], working across sales, marketing, customer success and product to make sure each strategy is financially robust and that cash flow and profitability stay front and centre. His judgement is direct: "As a CFO today, you're not doing that. Then, you know, you're not adding as much value as you are supposed to be adding" [4]. The stakes extend to fundraising, and here he speaks from having been a VC. On one deal the firm had decided to invest, then found in diligence that the company could not prove its numbers. "They were not lying to us... They just could not prove that the data was correct." Trust collapsed and the deal died [4]. "The accuracy, the timeliness, the auditability, all of it boils down to how robust your financial stack is" [4].

On building and funding the company

Zenskar raised about $7 million led by Bessemer, and the raise was deliberate rather than opportunistic: billing, rev rec, reporting, collections and usage tracking make for a large, complex product surface that needs "a relatively larger engineering team than most companies that start out" [2]. More than half that money is still in the bank, with the team at 38, roughly half engineering and design and half go-to-market, and close to 100 customers, most of that growth in about eighteen months [2]. He describes being in no hurry to raise again and "secretly hoping that our revenue kind of just, you know, gets us to profit sooner than we need to raise" [2], consistent with the earlier sequence he laid out of product-market fit, then predictable revenue, then break-even, then profit some years out [1].

On competing in a crowded category, his position is that crowding is confirmation, not a warning. "Any large market where there is a real pain point will be competitive that's just how capitalism works" [2][3], and what investors are actually testing is whether the differentiation is real and articulable. His advice to founders is about conviction: "you really need to believe that you will win. And once you believe it, then you can communicate it" [2], because "investors know a lot less about your space than you do... They don't know the pain. They're kind of riding on your belief" [2]. He also names what VCs screen for, having invested himself: large markets, timing, and defensibility in the business model [3]. On demand generation, outbound still works despite the received wisdom, inbound word of mouth has kicked in as early customers refer peers, and paid is a small part [2]. The number he watches most closely now is dollars spent per dollar of pipeline generated, because the sales cycle is long enough that cost per dollar of ARR lags by six to eight months; the target he works to is four to five dollars of qualified pipeline per dollar spent, with the holy grail being a dollar of revenue for a dollar of go-to-market spend [2]. Internally he describes the company as tech-first with little supply chain, its operations being HR, vendor and customer documentation work, where the friction is simply that every vendor has different processes, so aligning them to Zenskar's policies, documentation and NDA takes human back-and-forth [1].

On AI

His stance on adoption is categorical: "Every business needs to incorporate AI in their stack today. If you're not incorporating AI today, forget incorporating. You have to be an AI first company if you're not doing that as a business, it's only a matter of time before you die" [4]. Inside Zenskar that starts with an AI-native engineering stack, invisible to customers, and shows up in the product two ways: uploading a contract PDF and having AI read the terms and generate invoices and revenue entries instead of keying every term in by hand, and asking the system natural-language questions about revenue or churn for a cohort instead of running reports manually [4].

He also sees AI as the force pushing usage-based pricing into the mainstream, which was part of the timing thesis three years ago when AI "wasn't as mainstream as it is today" [3], and which shows up now in interest from AI companies [2] and in his view that adding AI features forces a reckoning with consumption-driven billing and measurement [6][10]. On the broader displacement question he is calm, reaching for the automobile analogy: when cars arrived people asked what would happen to horses, and what emerged was a more efficient way of living. "I don't think human jobs are going anywhere. People will just be doing higher level stuff that AI will not be able to do," truly intellectual work he still thinks is hard for AI to take over, while conceding "never say never" [3].

Takeaways

• Usage-based pricing breaks billing because the quantity leaves the contract: "The contract only has the pricing. It does not have the quantity... that information resides outside the contract" [3]
• Billing errors are asymmetric and underbilling is the dangerous one, since overbilled customers complain and underbilled customers stay silent while you lose revenue [3][4]
• Homegrown billing systems decay because they are built reactively, by engineers who are not finance experts, and never by a team's best engineers; they work for six to twelve months and then need constant maintenance [4]
• Price on the customer's value lever, not your cost lever: a telemedicine vendor switching from video minutes to patients served closed more deals [4]
• Judge a billing system on time to invoice, accuracy of invoices, and cost of billing including the opportunity cost of finance staff doing manual work [4]
• A VC deal he worked on died in diligence because the company could not prove its own numbers, not because it lied: "your house has to be in order for you to be able to raise money" [4]
• Competition validates a market: "Any large market where there is a real pain point will be competitive that's just how capitalism works" [2][3]
• Pulling usage straight from a customer's data warehouse instead of requiring API integration removes the engineering dependency that stalls finance-led implementations [2][3]
• The current guiding metric at Zenskar is dollars spent per dollar of pipeline generated, targeting four to five dollars of qualified pipeline per dollar spent, because long sales cycles make cost per dollar of ARR lag [2]