Why Every Finance Job Suddenly Wants Python, And Why Almost None of Them Need It

2026-09-07

I closed the books the same way for most of a year before I noticed the pattern. Somewhere between reconciling an intercompany account and chasing down an invoice that had taken three months to arrive, I would take a break and scroll LinkedIn, and the same small irritation would find me again. A job posting for something that read, line for line, like my own role, general ledger, month-end close, balance sheet reconciliation, would end with a line that had no business being there: proficiency in Python and MySQL required. Not preferred. Required. For a job that was, by every other line in the description, an accounting job.

My first guess was the cheap one. Recruiters copy templates. Somewhere, years ago, a tech-hiring boilerplate leaked into a finance one, and nobody has bothered to delete the line since. That explanation is comfortable because it costs nothing to believe and asks nothing of you in return. It also does not survive contact with the actual postings. JPMorgan runs a real, deliberate Python curriculum, built specifically for its business analysts and traders, aimed at people with no programming background at all. KPMG's Python and SQL postings are not scattered randomly through its accounting roles either, they cluster tightly inside a specific job family, Audit Data Engineering, Data Analytics, Technical Associate, sometimes explicitly preferring a computer science or data engineering degree over a straight accounting one. Neither of these is a copy-paste accident. But neither of them is describing my job either. JPMorgan's push sits in markets and investment banking. KPMG's sits in a distinct analytics practice bolted onto audit, not audit itself. The demand was real. It just was not evenly spread, and the four-language bundle people worry about, Java, C++, SQL, Python, all lumped together as one anxiety, was never really one thing to begin with. Java and C++ build the systems finance people use; almost nobody using SAP needs to know either. SQL and Python cluster somewhere else entirely, and even there, unevenly.

The unevenness turned out to have a shape. Wherever I looked closely enough, the roles that genuinely wanted this skill were not doing my kind of work. They were doing FP&A's kind of work, and FP&A's own daily material, budgets, forecasts, variance explanations, sounds every bit as far from a keyboard as mine does. So I went looking for the actual mechanism, and it was more specific than I expected. A budget is not one document, it is twenty department submissions in twenty slightly inconsistent spreadsheets that someone has to fold into a master file every cycle, a data-wrangling problem wearing a budgeting costume. Variance analysis, done at real transaction volume rather than a tidy trial-balance summary, is fundamentally a join-and-compare operation across periods, which is exactly the operation a query language was built for and a pivot table starts to buckle under. And increasingly, the numbers an FP&A analyst needs do not live in one place at all. One financial-systems posting exists specifically to pull data out of a CRM, a banking platform, and an ERP at once and make them agree with each other, three systems that were never designed to speak the same language, reconciled by hand otherwise. None of this replaces judgment. Nothing decides whether a budget assumption is realistic, or explains to a manager why marketing overspent. What changed is the plumbing sitting just beneath that judgment, and the plumbing is where the demand for code actually lives.

Which raises the obvious question: if a company already runs a dedicated automation team, why would it also want its finance people writing scripts? The honest answer is that a shared automation team is a queue, and queues rank by size and sponsor, not by how much time they would save a mid-level analyst, and worse, that team has no idea what a trailing three-month accrual average is or why an invoice can take three months to arrive, so every request costs a conversation that loses something in translation. A person who is both the domain expert and the builder skips that conversation entirely. This has an official name now, citizen development, and it exists for boring, structural reasons rather than any fondness for coding as a virtue. But the moment I looked at the other side of that coin, an old instinct of mine, the one that flags anything touching a financial statement, started flashing. A spreadsheet or script that quietly feeds a number into a set of accounts is exactly what auditors call end-user computing, the same risk category that has drawn increasing regulatory scrutiny for years, and for the same reason every time: nobody reviewed it, nobody tested it, and nobody can easily prove it is right. The honest resolution is not coder versus non-coder. It is prototype versus production. Writing a query to pull your own reconciliation is advanced spreadsheet work with a different accent. Turning that into something that runs unattended and feeds the ledger is a different animal, and correctly belongs to a team that can version it, test it, and put it through the same change control as everything else that touches the books.

By this point I had a real, narrow answer, and it should have settled the question. It did not survive my own experience of the job market for very long, because I kept noticing something else entirely: people listing Python and MySQL as key skills without being able to tell you why they learned them, and people producing working code by pasting a prompt into an AI tool, copying the output, and moving on without much idea what it did. My instinct was that this made the whole requirement a kind of theatre. It turns out to be closer to the opposite. A recent hiring survey found the exact same failure mode dressed in different clothes, job seekers admitting to claiming Google Analytics expertise without knowing what it was, self-described Excel experts freezing at a basic formula in their first week, and this is not new to Python at all. Long before anyone worried about coding, a majority of IT leaders were already on record saying most technical resumes exaggerate experience. Nobody spends effort faking a skill nobody is checking for. The fakery is not evidence the requirement is hollow. It is evidence the requirement is real enough to be worth performing.

The copy-paste half of the pattern turned out to have its own name too, coined only last year to describe exactly this: generating code through an AI and running it without reading or understanding what came back. Its own definition carries a clean fork built into it: if there is real human review of the output, it stops qualifying as that by definition. Which means the same visible act, someone pasting in code they did not personally type, is compatible with two opposite realities. One is a person who has no way of judging whether what came back is correct, running it until it happens to work. The other is a person directing the tool with real judgment about what correct should look like, and checking the answer against that judgment before trusting it. From the outside, the fraud and the expert produce the identical object. That is precisely why this looks like a strange new problem instead of what it actually is: the same old gap between the person who understands a number and the person just moving cells around, wearing a costume in which both of them can now produce identical-looking output.

I could not let the India-specific version of this question go, because it is the version I actually live inside. The commerce-graduate pipeline here is genuinely oversupplied: barely half of Bachelor of Commerce graduates were rated employable in 2024, down from the year before, and an older, starker study once put employability in accounting-specific roles below three percent. A market that saturated does exactly what you would expect to any skill perceived as scarce: certificate courses in Python for commerce students have started showing up inside commerce departments themselves, and one such course, run through a well-known Indian institute, enrolled well over twenty thousand people while barely two thousand ever became certificate-eligible, a much larger appetite to be seen learning something than to actually finish learning it. Every part of that supports the noise theory cleanly.

And yet, sitting right beside that saturation, is a genuinely large and fast-growing exception. India's global capability centres already employ close to two million people and are projected to approach three and a half million within the decade, and a report from the accounting profession's own global body states plainly that entry-level roles inside these centres are increasingly built around data analytics and FP&A skills from day one, not bolted on later. That is not a rounding error. The two facts sit together once you notice that scrolling LinkedIn for these postings is not the same as standing on the actual road most commerce graduates travel. It is closer to standing in one particular, brightly lit parking lot, global-brand centres advertising a specific, genuinely code-adjacent kind of work, and mistaking it for the whole highway, most of which still looks nothing like it.

The centres themselves have their own reasons for wanting this, and the reasons turned out to be less about the work itself than about what the work is meant to prove. The industry has a name for the arc these centres are expected to travel, cost arbitrage, then process excellence, then value creation, and a senior leader inside one of the firms that advises these centres said, almost as plainly as anyone says anything in public, that the model built on labour cost alone will not survive rising costs and geopolitical pressure, and that the work has to visibly move up that ladder or the centre itself becomes hard to justify. A capability centre that only ever does transactional work is a target for the next cost-cutting review. One that can point to genuine analytics work is not. Wanting Python in the job description, in other words, is partly about the task and partly about the centre's own survival inside its parent company's org chart, which is a completely different, more self-interested motive than "the work requires it," even when both are true at once. It is also worth admitting that almost everyone telling this particular story, the consultancies, the industry bodies, profits directly from centres believing it. The real demand and the convenient narrative are not the same thing, and they are not easy to fully separate.

Somewhere in the middle of all this I asked myself the question I probably should have asked first: does any of it actually need a real programming language, or does Excel already do this? The honest answer is that Excel, and specifically Power Query sitting inside it, covers a genuinely large share of the ground, real joins, real merges, refreshable reports, the exact kind of consolidation work that eats an FP&A analyst's week. But it stops at a specific, nameable wall. It can only read, never write back. It is not guaranteed to filter at the source the way a database does, a practitioner who had used both for twenty-five years benchmarked this directly and found Power Query pulling entire tables locally before filtering them, where a properly written query filters on the server first. And SAP's own equivalent, a query tool built explicitly for people who do not know its programming language, hits the same kind of ceiling from the other direction: joins and dumps a handful of tables cleanly, but cannot express real conditional logic, and cannot reach one inch outside SAP's own tables to touch a CRM or a bank feed sitting anywhere else. It is the same wall I had already found once, from a completely different direction, the one separating a single, well-governed system of record from data that has to be assembled across several that were never designed to agree.

Which left one question that felt like it should have made everything before it pointless: if AI can now write the code itself, why does any of this still matter? I expected this to be the thread that dissolved the whole argument. Instead, it handed me the cleanest evidence in the entire investigation, because a nearly identical transition has already played out in full, in under three years, in a different corner of the same industry. In 2023, "prompt engineer" was the job everyone wanted, no technical background required, salaries into six figures, the entire pitch reducible to being good at talking to an AI. Three years on, that standalone title has collapsed by something like half, by some counts closer to two-thirds, depending on who is counting. In the very same window, postings that list prompt engineering as one required skill inside a more technical role more than doubled. The skill did not die. It moved house, into roles that are more demanding than the original hype job, not less, because the easy layer, clever wording, is precisely what better models absorbed, while the harder layer, catching a wrong answer, designing a system that fails safely, did not go anywhere and became more exposed once the easy layer stopped hiding it. Ask developers themselves which matters more for getting hired today, judgment or fluency with the AI tool, and both juniors and the seniors who supervise them answer judgment, by a wide margin, even inside the one profession AI has reshaped the most visibly and the fastest.

I keep coming back to a specific artifact instead of an abstract argument, because the abstract version never quite lands the same way. Every finance team I have ever been part of has had one person with a workbook nobody else fully understood, a maze of nested formulas and named ranges that quietly held half the department's reporting together. Nobody ever mistook that workbook for the actual skill. It was evidence of the skill: this person notices what is wrong before anyone else does, and goes and fixes it instead of working around it, patiently, using whatever tool happened to be sitting on the desk that decade. Python is this decade's version of that same workbook, no more and no less. And if an AI can now build the workbook on request, the trait it was always standing in for does not disappear along with it. It just stops hiding behind the object, and starts showing up nakedly in the one place a costume was never able to reach: the follow-up question, asked to whoever is claiming credit for the answer.

I still scroll the same postings most evenings, mostly out of habit now rather than anxiety. I read the Python line differently than I used to, though. It no longer reads like a verdict on whether I am keeping up. It reads like a small, imperfect proxy for a much older question that never had a clean way of being asked directly, does this person notice when a number is wrong, and can they tell you exactly what would need to be true for it to be right, dressed, for one particular decade, in a language everyone happened to agree on naming out loud.

Notes: JPMorgan's Python curriculum and its focus on business analysts and traders is drawn from the bank's own published training material and subsequent financial-industry reporting. KPMG's audit-technology and data-analytics job family is drawn from a sample of the firm's own current job postings. FP&A automation examples are drawn from current job postings at Databricks, Onmo, Lendable, Herbalife, and OLX. The citizen-development framework and its adoption figures are drawn from industry research frequently cited by automation vendors, so the more flattering numbers should be read with that interest in mind. Resume-exaggeration figures are drawn from a 2026 Express Employment Professionals-Harris Poll and a longer-running TEKsystems survey of IT professionals. "Vibe coding" and its definition trace to Andrej Karpathy's original February 2025 description. Indian graduate employability figures are drawn from Wheebox's India Skills Report series and an older Aspiring Minds employability audit; the accounting-specific figure in particular is dated and should be read as historical context rather than a current statistic. Global capability centre employment and growth figures are drawn from ACCA and industry analyst reporting, and the maturity-curve framing draws on commentary from KPMG's India GCC practice; both come from parties with a commercial interest in the growth story, which does not make them false but does mean they deserve the same scepticism as any other interested source. Power Query and SAP Query limitations are drawn from practitioner forums and community benchmarking rather than formal studies, and reflect how these tools behave in practice more than any official specification. Junior-developer employment and prompt-engineering figures come from a mix of Stanford Digital Economy Lab research, a large-scale study of generative AI adoption, Gartner's public forecasts, a BairesDev developer survey, and industry hiring commentary; exact percentages vary noticeably by source and should be read as a consistent direction rather than a precise number.