To know what to bill a client, someone read the agreement, opened the spreadsheet, fetched each feature and perk by hand and computed the amount. Every month, every client.
The exceptions became rules
A performance-management software company replaced monthly spreadsheet archaeology, contract re-reading and hand-checked tax treatment with a billing system that computes every invoice from the subscription record and asks a person only to confirm.
This is one of Jestor's earlier cases. It was recorded in April 2022, the same month the company was acquired by UOL EdTech, the education arm of Grupo UOL. The company has since been merged with two sister platforms under its own brand. Everything below describes the billing operation as it was at the time of the case.
A performance-management company whose billing was hard by design.
The sales team could offer different products and custom perks per client. Clients sat in different countries and states. Two axes of variation, product and jurisdiction, multiplied across a growing client base.
Performance management software
2015Founded
YCWent through Y Combinator
2022Acquired by UOL EdTech
1,500+Client companies today, under the merged brand
1 clickWhat approving a computed invoice takesThe published case's own description of the approval step. It is how the review is done, not a measured time saving.
3Kinds of contract events the case names as automatedRenewal dates, scheduled adjustments and grace periods. The count is the source's list in the "After" section, not an estimate.
2022Year the case was recorded, and the year the company joined its current ownerPublication date of the case, and the owner's own announcement of the acquisition.
1,500+Client companies today, under the merged brandThe current owner's own published figure, March 2026. It describes the merged brand, not the company in the case.
“With our product, there are many different things that impact the invoice amount. Managing everything through spreadsheets got unsustainable, with a lot of small details going unnoticed, which means charging less than we should. Jestor's automations solved this issue to the point we're not only saving time, but money too.”
André LevyCFO, in the 2022 published case
BeforeAfter
- Re-reading agreements and spreadsheets each monthOne subscription record per client, holding the terms the invoice is computed from
- Fetching features and perks by hand to compute the amountThe system computes each invoice from the record on the billing cycle
- Watching for expirations and grace periodsRenewal dates, scheduled adjustments and grace periods stored as events and executed automatically
- Choosing payment platform and tax treatment per clientThe system detects both from the subscription's jurisdiction and terms
- Double-checking every invoice for withholding rulesRules applied once, in the computation, the same way every time
- Explaining exceptions to leadershipExceptions encoded as rules; leadership reviews a computed list instead
- Subscription data relayed through formsA flow from sales into the subscription record, being built at the time of the case
The deal structure and the sales team's freedom to customise stayed. The payment platforms stayed. The product and its engineering team were not involved. The company did not standardise its way out of the problem; it wrote its own rules down and had them run.
The bottleneck was operational, not commercial
Qulture Rocks builds software for managing teams and culture: performance reviews, feedback, OKRs and employee satisfaction. It was founded in 2015, went through Y Combinator, and had operations outside its home market. In April 2022 it was acquired by UOL EdTech, the education-technology arm of Grupo UOL; the founder stayed on as CEO. In March 2026 the owner merged it with two sister platforms, corporate-learning and training tools, under the Qulture Rocks brand, serving more than 1,500 client companies.
Subscription software should be simple to bill. Qulture Rocks was not, and by design. Its sales team could offer different products and custom perks per client, which changed not just the amount to bill but how the amount was calculated. On top of that, clients sat in different countries and states, so payment methods and tax withholding rules changed from one to the next. Two axes of variation, product and jurisdiction, multiplied across a growing client base.
That is why the bottleneck was operational and not commercial. The flexibility was winning deals. The cost of it landed on the finance team once a month, when every invoice had to be reconstructed from agreements and spreadsheets, and the alternative on offer, standardising the deals to fit an off-the-shelf billing tool, would have given up what was working.
The expertise about how to bill lived in people
“With our product, there are many different things that impact the invoice amount. Managing everything through spreadsheets got unsustainable, with a lot of small details going unnoticed, which means charging less than we should. Jestor's automations solved this issue to the point we're not only saving time, but money too.”
Whether a contract was about to expire or a client was inside a three-month grace period, nobody would know unless a person was checking for it. The spreadsheet held the fact; it did not raise it.
Clients in different jurisdictions meant different withholding rules and different payment platforms. Getting one wrong meant a bad invoice and a long correction, so everything was done carefully and then double-checked, which is another way of saying done twice.
The pattern: the team's expertise about how to bill lived in people, and it was applied by hand every cycle. Traditional finance platforms and ERPs had been researched and tried; none covered the exception types the company actually had. Nothing was broken. But a growing client list meant errors were becoming likely, and every error here is money not collected.
Item by item, what did each job before and what does it today
| What did this before | What does it today |
|---|---|
| Re-reading agreements and spreadsheets each month | One subscription record per client, holding the terms the invoice is computed from |
| Fetching features and perks by hand to compute the amount | The system computes each invoice from the record on the billing cycle |
| Watching for expirations and grace periods | Renewal dates, scheduled adjustments and grace periods stored as events and executed automatically |
| Choosing payment platform and tax treatment per client | The system detects both from the subscription's jurisdiction and terms |
| Double-checking every invoice for withholding rules | Rules applied once, in the computation, the same way every time |
| Explaining exceptions to leadership | Exceptions encoded as rules; leadership reviews a computed list instead |
| Subscription data relayed through forms | A flow from sales into the subscription record, being built at the time of the case |
What was not replaced. The deal structure and the sales team's freedom to customise stayed. The payment platforms stayed. The product and its engineering team were not involved. The company did not standardise its way out of the problem; it wrote its own rules down and had them run.
The chain, end to end, for one billing cycle
- 1A deal closes and the subscription record is createdPerson
With products, perks, jurisdiction, payment method, renewal date, adjustments and grace periods.
- 2The system computes each invoice on the billing cycleAutomated
It runs through every subscription, applies its tax rules and payment platform, and computes the amount.
- 3Anything the rules cannot settle is flaggedAutomated
A contract due for renegotiation, for example.
- 4The team reviews the list and approves each invoice with one clickPerson
A real check, not a formality: the case describes the team confirming the information before approving.
- 5The invoice is issued through the right payment platformAutomated
For that client, the one the record already named.
- 6The client paysExternal
Outside the system, on the schedule the payment platform already keeps.
- 7Scheduled renewals and adjustments change the recordAutomated
For the next cycle, without someone watching the spreadsheet.
The hard links are 1 and 4. The computation is exactly as right as the record it reads, so whoever creates the subscription is where accuracy is decided; that is why the company was moving that step from forms to a direct flow from sales. And the click in step 4 is a real check, not a formality: the case describes the team confirming the information before approving. The design keeps a person at both ends and takes them out of everything in between.
“I've used a lot of different dedicated finance platforms before, but they were never able to solve 100% of the problems they should. Spreadsheets were always present as workarounds, as ways to replace features that should have been there. Even something as simple as tax withholding could sometimes be a challenge on those platforms, or even impossible.”
Every change, with the basis beside it
| Indicator | Result | Where it comes from |
|---|---|---|
| Invoice computation | From reconstruction by hand each month to computation from the subscription record | Published case, "Before" and "After" sections |
| Contract events | From watching the spreadsheet to scheduled renewals, adjustments and grace periods executed automatically | Published case |
| Tax and payment treatment | From a manual second pass to detection from the subscription's jurisdiction | Published case |
| Approval | From a full manual cycle to review and one click per invoice | Published case |
| Under-billing | Described by the CFO as details that went unnoticed and meant charging less than owed, now caught | CFO quote in the published case; no amount recovered is stated |
No time or money figure is claimed here because none was measured. The CFO says the company is saving time and money. The case gives no hours per cycle, no error rate, no amount recovered and no revenue effect. This write-up reports the claim as the CFO's and stops there.
"Instant" means computed, not paid. The case describes billing as instant in the sense that invoice amounts are computed by the system rather than assembled by hand. Approval, issuance and payment still take their time.
No company-scale figure from the case is available. The original case published no client count, revenue or team size. The 1,500+ figure in this write-up is the current owner's, from 2026, and describes the merged brand, not the company in the case.
What this case does not measure
Worth naming, because it is usually what gets inflated.
The case was recorded in April 2022. That same month the company was acquired by UOL EdTech, and in March 2026 it was merged with two sister platforms under its brand. Whether the billing system described here still runs, and for which of the merged entities, is not known to us.
All descriptions and both quotes come from the company's finance team as published. No process was independently observed.
Hours per billing cycle, invoice error rate, revenue leakage before and after, days sales outstanding: none appear in the source. They are the numbers a buyer would want and they were not measured.
Unlike Jestor's other cases from the same period, this one carried no header numbers. The 1,500+ figure is the owner's and describes a larger, merged business.
At the time of the case, subscription data still came in partly through forms. The direct flow from sales is described as being built.
The CFO's and analyst's names and titles appear in Jestor's own case and were not confirmed against an independent source here.
Leakage is the failure mode of flexible pricing
| Indicator | Number | Source |
|---|---|---|
| Revenue leakage as a share of EBITDA | 1% to 5% per year | MGI Research, as cited by billing-software vendors in 2025 |
| Revenue lost to billing errors and uncollected charges | "Up to 5%" of revenue | EY estimate, as cited by a payments provider |
| Executives who see revenue leakage as a systematic problem | 45% | BCG survey, as cited by a billing-software vendor |
Revenue leakage is a field where the numbers circulate through vendors of billing software, each citing a consultancy or research firm and none linking to the original. The range is consistent, low single digits of revenue or EBITDA, and that consistency is the only reason it appears here. A reader should treat the exact percentage as unverified.
The mechanism the case describes, a perk agreed in a deal and not carried into the invoice, is the textbook form of it. The more a sales team is allowed to customise, the more places there are for a term to be agreed and not billed. That is a strong reason to standardise, unless customisation is winning the deals, in which case the answer is to make the record the source of the invoice.
"Companies lose up to 5% of revenue to leakage" appears in most vendor material and is attributed to EY, but no primary EY publication with that figure is readily found. It may be right. It should not be a line in a business case.
The system is built to fit, and responsibility for it stays with us
Qulture Rocks did not have a bad process. It had a good deal structure and a finance team that knew every exception, applying that knowledge by hand once a month. Off-the-shelf tools would have asked the company to give up the exceptions. The question a bespoke system has to answer is what happens in year two: a billing app nobody can change becomes the new spreadsheet in three years, with a login.
One builder owns each request from start to finish, and one is always in execution.
A new rule, a new automation or a new report comes in through the same channel, without becoming a new project.
If what was built is not right, it is rebuilt. Unlimited revisions within the subscription.
Seats are never the billing unit, which matters when finance, sales, leadership and operations all touch the same records.
People learn to use their app the way they learn any app, by opening it. Building, configuring and maintaining stays on our side.
Full export at any time, by CSV and API. SOC 2 compliant, no exit fee. Pause in one click and the systems keep running.
Methodology and sources
The before-and-after descriptions and both quotes come from the case study Jestor published in April 2022, written from interviews with the company's finance team. They are the team's own account and were not audited. The analyst's quote was shortened by one sentence that describes the team designing the system itself, a working model Jestor no longer offers. Names and titles are as published in that case.
Founding year and accelerator from the company's own material. The April 2022 acquisition from the acquirer's own announcement. The March 2026 merger of three platforms under the Qulture Rocks brand and the 1,500+ client figure from the acquirer's announcement as covered by business press.
MGI Research, EY and BCG figures as cited in 2025 billing-vendor material; none verified against a primary publication.
No time saved, amount recovered, error rate or revenue effect is claimed as a result, because none was measured in the source. No company-scale figure from the time of the case exists, and the current owner's figure is labelled as such.