On 22 July 2026 Avalara published research carried out by Censuswide among 250 CFOs and senior finance leaders at Indian companies working with AI agents. Seven in ten said the pressure inside their organisation lands mainly on deployment speed, and one in ten could not promise a regulator or auditor a clear account of what an agent had done.
Revenue accounting is where the missing explanation turns expensive: under Ind AS 115, a company books income promise by promise as each obligation is met, and auditors test exactly that judgment before any other. Pranay Raj Kanakala builds systems that can survive the test. As an SAP Revenue Accounting and Recognition consultant at MyTekX Inc., he designed the revenue architecture for a global healthcare and medical technology group, covering thousands of contracts across North America, Europe and Asia-Pacific, and he leads and mentors a team of 15 consultants who deliver such programmes. In June 2026 the NextWave Awards jury gave the programme its Gold. He talked to Analytics Insight about how a posted figure learns to explain itself.
Happy to be here. The first thing that breaks is the explanation, because software posts an entry in milliseconds, and eight months later somebody asks why that amount, on that date, against that contract, and by then the configuration has changed twice, half the project team has moved on, and the answer gets assembled from memory and old email threads. A system that produces a correct number but cannot reproduce the reasoning behind it has bought speed and paid for it with evidence.
With treating the audit trail as part of the entry itself, so the evidence gets generated at the same moment as the posting. Every revenue decision comes from a rule that finance approved in writing, the accounting event carries a trace of which rule fired, and my working test is blunt: pick any figure in a closed period and ask the system to name the rule behind it. When the architecture is right, that answer takes a minute.
Take a hospital group buying a scanner, a software licence and a five-year service contract on one order. Three promises, fulfilled at different times, each carrying its own share of the price. The scanner ships in March, so its revenue lands in March, while the service obligation runs across sixty months and its share arrives month by month, and how the total splits between the three depends on what each would sell for on its own. Handled in spreadsheets, that is days of work per contract, and I have watched two good accountants allocate the same contract differently, both of them defensibly, which is exactly the problem.
So we wired the quotation process straight into the revenue engine. The structure agreed with the customer arrives in accounting the way it was sold, the BRF+ rules split it into obligations and track when each one is fulfilled, and nobody retypes a contract into a spreadsheet at midnight before close. The judgment stays with finance, the bookkeeping of that judgment moves to the machine.
A smaller share than people assume, because the discovery phase decided what counts as a separate obligation and how a modification gets treated when a customer adds two service years in month fourteen, and those are finance calls, settled in workshops before anyone touched configuration. Automation then applies them the same way ten thousand times, which is where the accuracy actually comes from.
We ran the build through SAP Activate with agile delivery, from assessment to hypercare, because a revenue engine that goes live half-configured creates restatements. Once the rules are agreed, the next question is whether they still hold after the following update.
For answering that question every week rather than once a year, because regression testing means checking that yesterday's processes still work after today's update, and by hand it takes weeks, so teams sample a fraction and hope the rest held. Automated, the full set runs on every change, which cut our regression cycles by 65%, and honestly the part a CFO cares about is the defects that stopped escaping, because in finance an undetected defect is a wrong figure that travels into statutory reporting and stays there. The runs double as control evidence too, since each one leaves a record of what was checked and what passed.
Most weaker entries there failed on one point: nobody could say what the system does when the input is wrong. So list every decision the software now makes without a human, and write down the rule behind each one, and where nobody in the room can state the rule, that is the item that will fail the audit, and it belongs under human review until the logic exists on paper. High-value contract modifications sit in that category at most companies, and the work of writing their rules down is unglamorous and finite, which is what makes it worth doing.