Ankit Arya, Head of AI at Inscope, brings deep experience across AI product leadership, machine learning, enterprise automation, and applied research. As part of Inscope’s founding team, he is helping build software that enables companies to share accurate and compliant financial data with stakeholders. His background includes serving as Co-Founder and CTO of Mariana, where he worked on AI-driven market analysis and competitive research, as well as leading machine learning and AI product strategy at HackerRank. Earlier in his career, Arya worked at Meta on AI-driven recruiting automation and VR productivity, helped develop chatbot-based enterprise service automation as a founding engineer at Astound, and built production-scale machine learning systems at Collective[i]. His career spans practical AI deployment, product strategy, automation, and data-driven systems across both startup and large enterprise environments.
Inscope is an AI-native financial reporting platform built for accounting firms, finance teams, and enterprises that need to prepare, review, and deliver accurate financial statements more efficiently. The platform focuses on automating the manual work behind financial reporting, including roll-forwards, formatting, disclosures, footings, tie-outs, and consistency checks. Inscope positions its technology as a way to reduce reporting errors, shorten preparation cycles, and make audit-ready financial statements easier to produce. The company announced a $14.5 million Series A in February 2026 to expand its AI-powered financial reporting platform, with its product aimed at replacing fragmented spreadsheet-heavy workflows with a more systematic, compliant, and scalable reporting process.
You’ve worked across enterprise automation, machine learning, recruiting AI, VR productivity, and AI product leadership before taking on the Head of AI role at Inscope. How did that progression prepare you to tackle one of finance’s most manual and sensitive workflows?
Across enterprise automation, recruiting AI, VR productivity, and machine learning, I kept doing variations of the same hard thing: taking messy human work and getting an AI system to do it reliably enough that real teams would depend on it. Each domain taught a different piece. Deploying ML products at scale taught me what holds up under real volume. Building with LLMs as a founder taught me how these models actually behave, where they break, and how you shape them toward real precision rather than output that only looks good in a demo. And everywhere I worked, the products that earned trust kept a person in control and mirrored how the expert already worked, instead of forcing people into the machine’s logic.
What pulled me toward finance was a realization from building with LLMs: for the first time you could take genuinely unstructured data and build reliable automation on top of it, which simply wasn’t possible before. Of all the manual, human-led processes about to be reshaped by AI, financial statement preparation is one of the purest. The thesis I came in with, and the one everything we build returns to, is simple: the preparer’s job should shift to a reviewer’s. That’s the change worth working on.
Financial statement preparation and review has remained stubbornly manual for years. What made you believe this was finally a category where AI could deliver meaningful change?
If you look closely at what a financial preparer does, it’s really a data transformation pipeline. You pull data from a dozen systems that don’t talk to each other, like your ERP, your equity system, and PDFs full of contracts and schedules. You turn all of that into digestible outputs like balance sheets, income statements, and footnote tables. Then you add a layer of judgment on top: the commentary that explains what the numbers mean. It stayed manual for so long because those systems never connected, and older automation like rules engines and RPA, the scripted bots that mimic clicks, was far too brittle to survive the variety and the edge cases.
Two things changed. First, models can now take wildly varying inputs and structure them, and just as importantly, surface the edge cases for a human to check instead of silently breaking, as long as you build the verification step in behind them. Second, they can draft grounded commentary, because finance isn’t purely subjective. There’s a real rulebook to lean on, from FASB on how things are recognized and measured to the SEC on how they’re disclosed, with thousands of prior filings to learn from. What convinced me this was real was watching a check that a single model could never get right, the kind that takes many dependent steps, start working reliably once we ran it across a set of coordinated agents. With the right architecture, problems that look impossible to one model become tractable.
Why has enterprise finance been harder to transform with AI than many people expected?
The blunt version is that this is work people can go to jail for. The stakes are extraordinarily high, so the bar to automate any of it is correspondingly high. That’s a different universe from a consumer product where a mistake is an annoyance. Here a single wrong number can carry legal and regulatory consequences, and the person who signs off carries them personally.
On top of that, every company does this slightly differently, and the work is full of exceptions. Rules and templates handle the common path and then fall apart exactly where the real work lives. What defeated earlier software was never any single number, it was the need to understand an entire end-to-end workflow with all of its ifs and buts. High stakes, deep customization, and genuinely tangled workflows are why this category stayed untouched while AI transformed flashier ones.
What is the gap between generic AI tools and the kind of purpose-built AI required for financial reporting and compliance?
This is where I’d push back on the idea that it’s all about the model. Everyone has the same models. The difference is everything around them: what context you put in front of the model, at what moment, with what checks. A purpose-built system also compounds. The more it works inside one organization, the more it learns that company’s specific patterns and conventions, which a generic tool starts from scratch on every single time.
For finance there are a few things you can’t skip. The output has to be grounded in the source data, and every number has to be traceable back to where it came from, who or what produced it, and why. And the system has to know the limits of its own confidence, flagging what it isn’t sure about for a person rather than guessing. The real craft is in the experience around all of that. You can’t just throw an answer on the wall and leave the user to defend it. Designing for grounding, traceability, and a graceful handoff to a human is what separates a generic tool from something a controller will actually put their name behind.
What are the biggest machine learning challenges in building systems that can reliably understand the structure, relationships, and logic behind financial statements?
Start with a concrete example. A tie-out is when you make sure a number agrees everywhere it appears: a table against other tables, a table against the surrounding text, the text against itself, across an entire filing. Preparers do it every day. It sounds trivial, but you cannot just drop the whole document into a model with a clever prompt and trust the result, not at the precision this work demands. To make it reliable we had to break it into a coordinated system of smaller, checkable steps. Even the most routine check in finance can’t simply be swapped for a single model call.
That is the core machine-learning challenge, and it has three layers. The system has to understand how a particular customer works and keep learning from their feedback. It has to genuinely grasp the relationships inside a financial statement, since numbers tie out across statements, footnotes reconcile, and periods roll forward, rather than just reading the text. And once many agents are cooperating, you have quietly taken on a distributed-systems problem: getting the right context to the right step, putting checks and guards in place, mixing automated review with human review, and building the internal datasets that let you measure whether any of it is actually correct. The hard part was never getting a model to read a financial statement. It’s building the system around it that can reason, check itself, and explain where every figure came from.
How do you think about model accuracy, explainability, and error tolerance when AI is being applied to financial workflows where small mistakes can have major consequences?
There’s no single accuracy bar, and pretending otherwise is where people go wrong. These systems aren’t 100% accurate, and what’s achievable varies a lot by task. So the real work is communicating honestly about what the system did and where the risk sits. Rather than waving a blanket success rate, you point the reviewer at the items that carry the most risk, the material ones, and you’re explicit about what the system didn’t touch. That’s how you close the gap, instead of pretending it isn’t there.
Explainability has to be concrete, not a principle on a slide. When we run footing checks on a table, we show a mini calculator: the exact cells that were combined and the arithmetic the system used. If it made a mistake, you can see it in a second. On the model side, the single most important tool is strong evaluation suites that measure accuracy on real tasks. Beyond that, it comes down to learning to see with the model’s eyes. It is surprisingly easy to forget what the model can actually see. So you study what’s in front of it, you study how an expert reasons through the same problem, and you close the distance by giving the model the context that expert would have.
What does it take to earn the trust of CFOs, controllers, and auditors when deploying AI in compliance-heavy environments?
Trust starts with making it effortless to see what the system did. A user never sees your evaluation suite and doesn’t care that you average 95%. They’re looking at their filing, and on their filing the system might do worse than average, maybe its worst run of the day. No aggregate number comforts anyone in that moment.
So everything rides on the experience around the AI. You show clearly what was done, make it trivial to verify and correct, and make sure that correction actually teaches the system. These are people who are personally accountable for the numbers, so they don’t want a black box. They want to stay in control and see the work.
One case captured it. A user flagged a calculation error in a table and asked why the AI hadn’t caught it. Because every action was on the record, we could walk back through exactly what happened: the system had in fact flagged that figure as questionable, and it had been dismissed. The point isn’t who was right. It’s that a complete, shared record turned what could have been a finger-pointing exercise into a five-minute reconstruction. That kind of documented trail is what lets a finance team treat the system as a genuine partner.
Where do you think many enterprises go wrong when they try to introduce AI into critical financial workflows?
The most common mistake is aiming for full automation on day one. The instinct is to remove the expert; the better move is to make the expert far more productive and aim their judgment where it actually matters. When you try to take the human out entirely, you get something nobody trusts and nobody uses.
The second is treating this as purely a modeling problem and starving the part the user actually touches. How the work is presented, how easy it is to check and fix, often decides whether a tool gets adopted or quietly abandoned. A lot of teams discover too late that the model was the easy part.
If I were advising a CFO starting today: pick a narrow, painful, well-understood task rather than boiling the ocean, keep your experts firmly in the driver’s seat, and invest as much in the experience and the feedback loop as in the model itself. That’s the difference between a pilot that quietly dies and one that changes how the team works.
As AI becomes more embedded in reporting and review, how do you see the role of finance professionals changing over the next few years?
This is where the thesis I opened with pays off. The shift is from preparing to reviewing. Today most of a preparer’s time goes to mechanics: pulling data from scattered systems, building tables, running the same checks again and again. As AI absorbs that, the job moves toward reviewing the output, applying judgment where it genuinely takes a human, and handling the exceptions.
I see this as making finance professionals more valuable, not less. Their judgment, their institutional memory, and the accountability they carry get spent on the decisions that matter instead of on assembly work a machine can do. The best of them will be excellent at directing and checking AI output, catching the thing that looks subtly wrong, and working fluently alongside these systems.
I’d be precise about the speedup, though. AI compresses preparation, which can go from weeks to a fraction of that. It doesn’t compress the parts gated by external auditors and filing deadlines, which are a floor it can’t move. But shrinking preparation alone changes the rhythm of the function: a faster close, reporting that edges toward continuous, and more time spent on what the numbers mean for the business rather than on producing them. That’s a more strategic future for the profession, not a smaller one.
When you look across the enterprise AI landscape, what separates companies solving deep operational problems from those simply riding the AI wave?
I judge it with one test, and it has nothing to do with AI: how much would a customer hurt if the product vanished tomorrow? If the answer is “a lot,” it’s a real company. If the honest answer is “they’d barely notice,” it’s a company surfing the hype. AI doesn’t change that test. It just makes it cheaper to build a slick demo that fails it.
Go a level deeper and the durable advantage comes from how far into the work you’re willing to go. The last generation of software built the place where work happens, the surface people work on. This generation can build systems that do the work itself, including the complex, multi-step enterprise cases that most tools quietly route around. Once you’ve gone that deep, with the accumulated context and the trust that takes years to earn, a big lab can’t just walk in and take the business with a better base model. That depth is the whole game, and it’s where we’ve placed our bet at Inscope.
Thank you for the great interview, readers who wish to learn more should visit Inscope.
