Business Process Automation for Indian Companies: Where the Hours Actually Go

Business process automation is the use of software to run a repeatable, multi-step business process from trigger to finish, with people involved only where judgment is genuinely required. The work that decides whether it succeeds happens before any software exists: measuring where the hours in that process actually go.

Almost nobody does that measurement. MIT's Project NANDA reviewed more than 300 disclosed AI initiatives and found that 95% of generative AI pilots produced no measurable impact on profit and loss, concluding the cause was mishandled deployment rather than weak models (The GenAI Divide, MIT Project NANDA). Deployment goes wrong in a boring, specific way: the team automates the process it believes it runs, not the one it runs.

We build these systems for Indian companies out of Kochi, and the pattern is consistent. The process on the whiteboard has six steps. The process in the building has nineteen, four of which happen in WhatsApp and one of which is a person opening a bank portal to check something the ERP already knows.

What is business process automation, and how is it different from buying an automation tool?

Business process automation covers the whole path a piece of work travels, across every system and department it touches. Buying an automation tool automates one step inside that path. The difference matters because the time in most Indian back offices is not lost inside steps. It is lost in the gaps between them.

IBM frames business process automation as a strategy for automating complex and repetitive processes to streamline daily operations (IBM, What Is Business Process Automation?). That is accurate and it is also where most definitions stop. The definition does not tell you which of your processes qualifies, and that is the only question a founder actually has.

A useful working test: if you can name the trigger, name the finish line, and name every system the work passes through in between, you have a process. If you can only name the tools, you have a tool stack and an assumption.

Why do most automation projects fail before a single workflow is built?

Because the process was scoped from a description rather than from an observation. Somebody senior explains how the month-end close works, an integrator builds that, and then real data arrives and disagrees. The build was not wrong about the software. It was wrong about the process.

The second failure is quieter and more expensive: two departments use the same word for different numbers. We saw it at scale on the Parakkat Group command centre build, where eighteen systems ran across 52 branches and no two of them agreed on what a number meant. The problem was never a shortage of dashboards. Every system had its own login, its own export button, and its own definition. Answering a question like which branches are below reorder level meant asking a person to build a pivot, by which time the situation had moved.

The same MIT review found that buying from a specialist vendor succeeded roughly 67% of the time, against internal builds succeeding about a third as often. Our reading of that gap is not that internal teams are less capable. It is that an internal team is usually handed the described process, while an outside team has no choice but to go and watch the real one.

How do you find where the hours actually go?

You follow one real, recent instance of the process from end to end with a clock running, and you record every artefact it touched and every point where somebody waited. Not a typical instance. A specific one, with a date on it, including whatever went wrong that day.

The method we run before quoting any process automation work:

• Pick one real instance from the last two weeks. If the team describes it as unusual, that is a reason to keep it, not to discard it.
• Log every artefact it touched. Files, portal logins, WhatsApp threads, printed sheets, the spreadsheet on one person's desktop that nobody mentions in meetings.
• Time the work separately from the waiting. A process that takes three days and forty minutes of labour is a routing problem, not an automation problem, and automating it will buy you nothing.
• Mark every point where a human made a decision, and write down what information that human used to make it. This is the list that later tells you which steps can be deterministic and which need a person.
• Reconcile what you recorded against how the team described the process. The gap between the two is the finding. It is almost always where the hours are.

That last step is the whole exercise. The described process is the one people optimise in their heads; the recorded process is the one paying salaries. In most back offices we have mapped, the largest single block of time is not a task at all. It is re-entry: the same figure typed into a second system because the two systems do not share an identifier.

What does this look like on a real build?

On the Parakkat reconciliation engine we reconciled one full day of actual card and UPI settlements by hand before writing any software. Only when that day balanced did we design anything. The exercise cost a day and it changed the shape of the build.

What it surfaced was that the obstacle was identity, not arithmetic. A settlement line from an acquiring bank names a payment terminal. The ledger names a branch. Nothing connects the two. Multiply that across roughly fifty shops and two acquiring banks with different file formats, and the morning becomes manual matching that is too important to skip and too repetitive to do reliably.

So the first thing we built was not a matching engine. It was a crosswalk resolving every terminal to a shop and every shop to a ledger entity, and we did not stop until it covered 100% of terminals. A matching engine that resolves ninety percent of terminals is not an automation. It is a new manual task with extra steps, and the residue lands on the same accountant who was supposed to be freed.

The finished system now runs daily across ~50 shops, resolving two acquirer formats through one matching engine, and it has posted zero journals without a human approving them. That last number is a design decision rather than a limitation. The full build is written up in the card and UPI reconciliation case study.

“Neogen Media helped us successfully implement an AI agent ecosystem that has made our work faster, more organised and productive. Their team understood our requirements and built a practical system with the right level of human control.” - CA Anirudh Varma, Internal Audit Team, Parakkat Jewels.

The phrase to hold onto there is the right level of human control. That is not a courtesy to the client. It is the design constraint that decides whether finance signs off.

What should an Indian company automate first?

Start with the process that runs most often, needs least judgment, and has the cleanest input. Frequency compounds the saving, low judgment means the rules can be explicit, and clean input decides whether the thing works at all. A daily process beats a strategic one every time.

Beyond that, one ordering rule does most of the work: automate reads before writes.

• Reads are free. Pulling numbers out of eight systems into one view breaks nothing if it is wrong, and it tells you within a week whether your data is good enough to automate on.
• Writes to a system of record are gated. Anything that posts a journal, changes a stock figure, issues a document or messages a customer needs a person on the approval before it reaches the record.

This is why we usually start a group on reporting rather than on transactions. If the numbers cannot be trusted in a read-only dashboard, no amount of workflow logic will make them safe to write. We have written separately about why automated reporting collapses over metric definitions rather than over dashboards.

If you want that mapped against your own operation rather than against ours, that is the substance of our AI process automation work: we watch the process before we touch it, and the first deliverable is the map, not the build.

Where does business process automation break in Indian operations specifically?

It breaks on identity and on file formats. Indian multi-branch and multi-entity businesses generate the same transaction under several identifiers, and the systems that report those transactions each export a different shape of file. Nothing in a generic automation platform resolves that for you.

The failure modes we run into most often on Indian builds:

• Multi-entity structures. One brand, several registered entities, one point-of-sale estate. The ledger entity a transaction belongs to is frequently not derivable from the transaction itself, and has to come from a crosswalk somebody maintains.
• Settlement and statement files. Two acquiring banks will report the same rail in two formats, with different date conventions and different handling of transfers to head office. Real data corrected several of our assumptions on the first live run, which is normal and is why the first live run teaches more than any test against sample files.
• WhatsApp as an undeclared system of record. Approvals, price confirmations and delivery instructions live in threads that no system can read. Any map that ignores those threads is describing a process that does not exist.
• Scheduled ERP exports standing in for live data. When the answer to an operational question is a fixed-format Excel file that arrives tomorrow morning, the automation you need first is access, not workflow.
• Tax and fee splits treated as an afterthought. A card settlement is not one number. It is a gross, a merchant discount rate, and tax on that fee, and if the automation does not split them into their own lines the books are wrong in a way that only surfaces at year end.

None of these are AI problems. They are plumbing, and they are the reason a process automation engagement that opens with a model demo is selling you the last 10% of the work.

How is business process automation different from RPA and workflow automation?

The three describe different scopes of the same ambition. Business process automation is the end-to-end process across systems and departments. Robotic process automation is a bot imitating a person inside one application. Workflow automation is the routing and handoff logic that moves work between people.

• Robotic process automation (RPA) drives an existing interface: it clicks, copies and types the way a person would, which makes it useful when a system has no API and fragile when that system's screen changes.
• Workflow automation moves a task from person to person with rules and reminders. It is excellent at handoffs and does nothing about data that disagrees between systems.
• Business process automation sits above both. It owns the path, the data model underneath the path, and the decision about which steps a human keeps.

In practice the modern version of this is less about choosing a category and more about choosing where the determinism lives. On anything that touches money we keep the matching logic explicit and auditable, with no model guessing in the path, and use language models for the parts that are genuinely linguistic. The reasoning behind that split is set out in our piece on what actually breaks in finance automation.

What should you refuse to automate?

Refuse anything where the cost of a wrong answer exceeds the cost of a human minute, and anything nobody owns. Both rules get broken constantly, and both produce systems that technically work and are quietly switched off within a quarter.

Three specific refusals we hold to:

• No unsupervised writes to a system of record. An automation that posts to a general ledger without review is not a time saver, it is an unreviewed liability. We stage the journal and wait.
• No automation of a process with no named owner. If nobody owns the process today, nobody will own the exceptions tomorrow, and every automation produces exceptions.
• No automation of a step whose inputs are still in dispute. If two departments disagree on the definition of the number feeding a step, automating that step industrialises the disagreement.

There is a fourth that gets argued with, so it is worth stating plainly: we do not automate a process to avoid fixing it. Plenty of processes that look like automation candidates are really the residue of a bad handoff or a missing field, and the honest deliverable is a two-line change to how the work is recorded. That conversation loses us scope and saves the client a build. The same logic applies further up the funnel, which is why our note on what Indian SMBs should automate last argues against starting at the close.

Frequently asked questions

How long before we get time back?

The map takes days, not weeks, and it returns something immediately: you find out how much of the process is waiting rather than working. A first deterministic build on a well-scoped daily process is typically a matter of weeks to a first live run, and the first live run is where real data corrects the design. Expect that correction rather than treating it as a setback.

Do we have to replace our ERP or accounting software?

No. We read the files your existing systems already produce and write back into the ledger you already use. On the Parakkat reconciliation build nothing about the client's point-of-sale or accounting setup changed. The automation layer sits between the systems, which also means removing it later leaves the originals intact.

Our process lives in WhatsApp and spreadsheets. Is it too messy to automate?

That is the normal starting condition, not a disqualifier. What matters is whether the artefacts are consistent enough to parse and whether somebody owns the process. A messy process with a clear owner automates well. A tidy process with no owner does not.

Who from our side needs to be involved?

The person who actually performs the process, for the mapping, and whoever signs off on its output, for the approval gate. Not the whole department. The single most common cause of a wrong map is scoping the process from a manager's description without watching the person who does it.

Is RPA still worth using in 2026?

Where a system genuinely has no API and no export, yes. Everywhere else it is a fallback with ongoing maintenance cost, because it depends on screens staying where they are. Check for a file export or an API first. Most Indian ERP and banking systems have one, even when the vendor's default answer is a scheduled report.

Can an AI agent run the process instead of a fixed workflow?

For reading, interpreting and answering, yes, and that is where we use them. For the write path on anything financial, no. Explicit rules are auditable and a model's reasoning is not, and when the output is a journal entry rather than a suggestion on a screen, auditability is the requirement.

If you want to know where your own hours are going, the first step is not a platform decision. Bring one real process, and book a 30-minute call: we will map it against a real instance and tell you honestly whether it is worth automating or whether it just needs fixing.