How we replaced a broken Excel-based commission process with a SQL-powered automation engine — cutting a 24-hour monthly cycle down to 8 hours.
Every month, a team of finance specialists sat down with a sprawling Excel workbook. Their job: calculate commissions owed to dozens of brands and companies, account for every refund, reverse every applicable charge, and produce a payout file, all based on millions of order-level records.
It worked, until it didn’t.
This is the story of how we rebuilt that process from the ground up.
Our client is an e-commerce service provider that handles end-to-end order processing for a portfolio of brands and companies across multiple sales channels. Their business model is commission-based: for every item sold, they charge a percentage of the selling price. When a refund is issued, that commission is reversed.
At the end of every month, the client collects all the money on behalf of the brands they serve and pays each one their due share. Getting that number right isn't optional. It's contractual.
The challenge? The entire calculation engine lived inside Microsoft Excel.
Excel is a powerful tool. But it has hard limits, and this operation had long since crossed them.
Volume was the first wall. Processing millions of order-level records in Excel isn’t just slow; at a certain point, it simply isn’t possible. Row limits, memory ceilings, and file size constraints mean the workbook either crashed or had to be broken into smaller chunks, reintroducing the manual work the tool was supposed to eliminate.
Speed was the second. A single VLOOKUP across a large dataset could take minutes. Multiply that by dozens of lookup operations across a monthly order file, and the calculation cycle consumed enormous blocks of time, time that had to be staffed, scheduled, and supervised.
People were the third. Because the logic was embedded in formulas, cell references, and undocumented conventions inside the workbook, only a small group of trained specialists could run the process. They needed deep business knowledge: which commission rates applied to which brands, how refunds mapped back to original orders, how channel-specific rules interacted. Onboarding someone new wasn’t fast. Losing someone was a serious operational risk.
Scalability was the fourth. The client’s business was growing – more brands, more channels, more orders. Every new brand added complexity to an already fragile process. The Excel model wasn’t designed to scale. It was designed to get through the month.
The result: a monthly finance cycle that took 24 hours of skilled human effort to complete, with meaningful risk of error at every step.
We rebuilt the process in SQL, not as a shortcut, but as an architectural decision. SQL is purpose-built for exactly this kind of work: high-volume, structured, relational data with well-defined transformation logic.
Here’s what the new system does:
Every order processed during the month flows through the engine. For each order, the system identifies the applicable brand, retrieves the correct commission rate, and calculates the commission on the selling price. This happens at the individual order level, not aggregated, not estimated, not approximated.
When a refund is issued, the engine locates the original order, retrieves the commission that was calculated at the time of sale, and reverses it. This ensures the brand is not charged commission on revenue they didn’t keep, and that the payout calculation reflects the true net position.
The system handles all sales channels simultaneously. Commission rules, rate structures, and payout logic are stored as parameters, not hardcoded into formulas. Adding a new brand or a new channel means updating a configuration table, not rebuilding a workbook.
At the end of each monthly run, the engine produces a clean, reconciled payout file , structured, auditable, and ready for payment processing. No manual aggregation. No copy-paste between tabs. No human interpretation required.
24 hours to 8 hours
67% effort reduced
From limited rows to millions of records
Systematic, auditable system
The 67% reduction in effort isn’t just a time saving — it’s a structural change. The process no longer depends on a small group of specialists who hold the institutional knowledge. It no longer breaks down when order volumes spike. It no longer requires a skilled analyst to babysit a VLOOKUP at 11pm to hit a month-end deadline.
The finance team now spends their time reviewing outputs and resolving exceptions — not running the calculation.
Finance operations teams spend an average of 120 hours a month on manual reconciliation and commission processes, time that could be redirected to analysis, forecasting, and strategic decision-making. The reconciliation software market reached $3.52 billion in 2024 and is projected to grow to $8.9 billion by 2033[1], reflecting how broadly this problem is recognized across the industry.
But market-wide software isn’t always the answer. For businesses with specific commission structures, multi-brand payout logic, and high order volumes, off-the-shelf tools often require significant customisation or simply don’t fit. A purpose-built SQL engine, designed around your exact data model and business rules, can outperform a generalised SaaS product while giving you full control over the logic.
E-commerce businesses lose up to 1.5% of gross revenue annually due to reconciliation failures. For a company processing millions of orders and paying out brands every month, 1.5%[2] isn’t a rounding error; it’s a material financial exposure.
The problem our client faced wasn’t unique to them. It’s a pattern we see repeatedly in ecommerce operations: a process designed to operate at a certain scale, held together by skilled individuals and institutional knowledge, that eventually hits its ceiling. The fix isn’t always more people. And it isn’t always a new SaaS subscription.
Sometimes the right answer is to look at what the process actually does at a data and logic level and rebuild it in the right tool for the job.
In this case, that was SQL. The result was a 67% reduction in effort, a more reliable output, and a finance team that could finally focus on the work that actually needs human judgment.
If your finance operations are running on processes that were never designed to scale, we’d be happy to walk through what a rebuild could look like for your business.
Business Solution
For Indian manufacturing founders and CFOs navigating their next operational upgrade. The Tally vs ERP question for manufacturers is ultimately not about software preference, it is about operational maturity. There is a specific kind of Friday evening that every manufacturing...
April 22, 2026
Abhijay Kishore
Business Solution
Your Heading How we replaced a broken Excel-based commission process with a SQL-powered automation engine — cutting a 24-hour monthly cycle down to 8 hours. Every month, a team of finance specialists sat down with a sprawling Excel workbook. Their...
April 14, 2026
Anshuman Chhapolia
Business Solution
Every ecommerce finance team has lived this moment: the monthly close is approaching, your payment gateway shows one number, QuickBooks shows another, and the affiliate dashboard appears to be operating in a separate dimension entirely. You reconcile for hours, patch...
April 08, 2026
Adarsh Singh
Business Solution
You’re running a manufacturing business that’s doing well. Somewhere between ₹20 crore and ₹100 crore in annual revenue. You have a plant, a team, orders coming in, and real customers who depend on you. And yet, every week, something surprises...
April 01, 2026
Anshuman Chhapolia
Ecommerce
You're selling on Amazon, Flipkart, Meesho — revenue looks healthy. But quietly, 3–5% of your GMV is disappearing into a black hole of fees, return mismatches, and settlement gaps. Here's why it happens, and what modern D2C finance teams are...
March 24, 2026
Anshuman Chhapolia
