Somewhere in your drafts folder there is a job description. It asks for an MIS Executive with advanced Excel. It lists VLOOKUP and pivot tables. It mentions daily and monthly reports, coordination with operations and accounts, and reconciliation of some specific thing — vendor payments, stock, trip sheets, collections.
That document is the most accurate specification of your operational software that anyone in your company has ever written. It was produced by the person closest to the gap, it is specific about the failure, and it proposes a remedy: a human being, hired to be the integration layer between two systems that do not speak.
Which is sometimes right. This essay is about how to work out whether it is right in your case, because the comparison almost never gets made properly — the salary is a budget line and the alternative is a vague number nobody has established.
What the posting is really describing
Read your own JD back one clause at a time. Each requirement maps to a piece of software that does not exist.
| The clause | What it actually says |
|---|---|
| “Advanced Excel, VLOOKUP” | Two datasets must be joined, repeatedly, by hand. There is no shared key between two systems. |
| “Prepare daily MIS reports” | The data exists but produces no report on its own. Somebody assembles it each morning. |
| “Coordinate with operations and accounts” | Two departments hold different records of the same events, and a person reconciles the difference. |
| “Reconcile vendor / customer statements” | Your record and a counterparty’s disagree monthly, and nothing detects it automatically. |
| “Maintain trackers” | The system of record is a spreadsheet, maintained manually, with no constraints. |
| “Tally and Excel both required” | Tally is the ledger. Excel is everything Tally cannot do. The gap between them is the job. |
That last row deserves emphasis, because it is the clearest signal in the whole document. When a posting asks for both, it is naming the boundary precisely: the accounting system holds the financial record, the operational reality lives outside it, and a person is being hired to carry data across the gap every day, forever.
Run the comparison honestly
Here is where the analysis usually goes wrong. The salary is compared against a build quote, the build quote is larger, and the decision is made. But the two numbers are not comparable, for three reasons.
The salary is not the cost
An MIS Executive in an Indian metro costs somewhere around ₹3.5–6 lakhs a year fully loaded. But the role recurs: it is the same cost next year and the year after, rising. Three years of a mid-range MIS hire is ₹12–18 lakhs, and at the end of it you own nothing.
Add what the JD does not mention. Recruitment and the weeks of vacancy. Training, which falls on the manager the role was meant to relieve. And turnover — this is a job people leave, because it is repetitive by design. If you have posted the same role twice in eighteen months, that is not a hiring problem. It is the job telling you what it is.
The manual process has its own error cost
A person joining datasets by hand, daily, under deadline, makes mistakes. That is not a comment on the person; it is what the task is. Those errors cost: an invoice raised wrong, a payment made twice, a reconciliation that balances by rounding rather than by matching.
This cost is real and almost never measured, which is precisely why it does not appear in the comparison. It is also the cost that grows fastest with volume — the thing you are hiring because of.
The ceiling is closer than it looks
One person can reconcile a certain number of counterparties. Past roughly fifty, memory stops helping. Past about a hundred and fifty, the task is structurally impossible to do correctly and what you get instead is a plausible approximation delivered on time.
So the honest question is not “can one person do this?” It is “how many will this be in three years at our growth rate?” Because the software cost is roughly flat as volume rises, and the headcount cost is not.
- How many hours a week go into this task today, across everyone who touches it — not just the person you would be replacing?
- How many counterparties do you settle or reconcile with monthly? Where will that be in three years?
- Have you posted this role before? If yes, you are paying the recurring cost of a job nobody wants.
- What breaks when this person is on leave? If the answer is “the reports stop”, the role is load-bearing infrastructure with a notice period.
- What does an error here cost when it reaches a customer or a vendor, and how often does that happen?
When hiring is the right call
Often, and we would rather say so than pretend otherwise.
Hire if the process is genuinely still changing — if you are figuring out what the business does, a human is more adaptable than software and you should not freeze a process you have not settled. Hire if the volume is modest and stable and a well-built spreadsheet with one careful owner genuinely covers it. Hire if the work is mostly judgement rather than joining, because judgement does not automate and should not.
And hire if the reconciliation is against a counterparty who will not change how they send you data and cannot be integrated with. Someone has to do that, and it is a person.
The middle path most people miss
The choice is presented as build-or-hire, which is a false pair. The useful third option is to fix the specific join the JD is complaining about, and nothing else.
Most MIS roles exist because of one missing key. Two systems describe the same real-world thing — a trip, an order, a batch — with no shared identifier, so a human matches them by date and amount and plausibility. Establishing that identifier and making both systems carry it is often a few weeks of work rather than a full system, and it removes most of the daily task.
That is usually the highest-return intervention available in a mid-market operation, and it is invisible until somebody maps where the time actually goes.
Establish the number first
Whichever way you go, the decision deserves better inputs than a salary figure and an instinct. Before you post the role or take a build quote, find out what the current process costs: hours across all the people who touch it, error rate and what errors cost when they escape, and where the volume will be in three years.
That is what our two-week leak audit produces. Not a proposal — a number, with the workings. Sometimes it says hire the person, and we say so. What it does not do is leave the most expensive recurring decision in your operation resting on the only figure that was easy to look up.