Why CPAs Already Think Like Programmers

The syntax was new. The thinking was not.

Week 2 of Columbia Business School’s AI for Business & Finance program was structured as a hands-on Python bootcamp. At first, part of me wondered why a finance-focused AI program was asking us to spend so much time inside code.

I expected to learn a technical language. I did not expect the experience to change how I understood the accounting processes I had spent years performing—or to show me why finance professionals have an important role before an AI-enabled workflow is ever built.

The class was hands-on. We worked through Python notebooks one code cell at a time. I ran the code, changed it, created answers, and watched what happened. Sometimes the output appeared exactly as expected. Sometimes an error exposed something I had misunderstood. The professor then explained how each instruction worked and how those building blocks could later support data analysis, APIs, language models, and working applications.

As I worked through variables, functions, conditions, loops, APIs, and error handling, I began recognizing something beneath the unfamiliar syntax. I stopped seeing Python as a separate technical subject and started seeing it as a way of making the hidden logic inside finance processes explicit.

The experience reminded me of calculus in college: define a variable, give it meaning, apply a rule, and build forward one step at a time. It also reminded me of learning another language. Spanish was my first language, and I learned English later in life. Python had unfamiliar vocabulary and grammar, but learning through symbols, rules, and order was not new to me.

I still needed to return to the material and review how a data structure worked or which condition should be evaluated first. But I did not experience the subject as inaccessible. The more code I ran, the more clearly I saw the connection between programming logic and the structured thinking already embedded in accounting work.

Information has to mean something before a program can use it

The bootcamp began with variable types. We worked with strings, integers, floats, lists, sets, tuples, and dictionaries before moving into saved objects and reusable functions.

Viewed individually, those lessons seemed basic. A string holds text. An integer or float represents a number. A list stores a collection. A dictionary connects a key with a value. But running the examples made the concepts tangible. I could change an input, execute the cell again, and immediately see how the result changed.

As an accountant, I also began thinking about the business meaning behind the type of information being used. A customer name, an account code, a dollar amount, a date, and a transaction category may all appear in the same spreadsheet, but they are not interchangeable. A value that looks numeric may actually be an identifier. A list may preserve repeated items while a set removes duplicates. A dictionary may connect a code to the description or value that gives it meaning.

That was one of the first bridges between programming and accounting for me. Before a rule can be applied reliably, the information entering the process has to be understood and represented appropriately.

Functions and control flow made the connection clearer

The next step was learning how to package instructions into functions so the same logic could be reused. We then worked with control flow: if statements, loops, list comprehensions, and error handling.

This was where programming began to feel especially familiar.

An if statement asks whether a condition is true before deciding what should happen next. A loop repeats an action across multiple items. Error handling anticipates that the expected path may fail. A function receives defined inputs, performs a task, and returns a result that another part of the process can use.

Accounting processes rely on the same kinds of decisions. If support is incomplete, an item should not move forward. If an amount exceeds a threshold, another approval may be required. If a reconciliation difference remains unresolved, it must be investigated, corrected, or escalated. If the same calculation must be performed across many records, the rule should be applied consistently.

The terminology was different, but the structure was recognizable: define the information, apply the rule, evaluate the result, handle the exception, and determine what happens next.

I recognized programming inside the month-end close

The connection became clearest when I thought about the month-end close.

At different points in my career, I have worked in accounting environments affected by backlogs, changing responsibilities, inconsistent documentation, and processes that depended too heavily on what one person remembered. In those situations, completing the close required more than preparing the next journal entry or reconciliation. The process itself had to be reconstructed.

I had to understand which activities needed to happen first, which schedules depended on information from another team, what support was required before an item could be posted, what happened when a reconciliation did not agree, who reviewed the work, and where the evidence should be retained.

At the time, I was not thinking about programming. I was trying to make the close reliable, reviewable, and repeatable.

Python helped me see the same process in a different form. A close contains inputs, dependencies, calculations, decision points, thresholds, exceptions, approvals, and outputs. Some steps cannot begin until earlier work is complete. Some transactions follow a standard path. Others require judgment. A missing file may stop the process. An unresolved difference may require escalation. A journal entry may balance and still be wrong because it belongs to the wrong period, entity, account, or population.

That is more than a checklist. It is a decision system.

Programming makes that system explicit.

Programming forces hidden process knowledge into the open

In many accounting departments, process knowledge is spread across spreadsheets, procedures, emails, shared folders, close calendars, system settings, and the memory of experienced employees.

A process may appear stable because the same people have performed it repeatedly. But the knowledge becomes fragile when the team changes, the volume increases, a system is replaced, or management decides to automate the work.

A computer cannot reliably execute a rule that exists only as an informal understanding. The organization has to explain what the rule actually is.

That requirement can expose ambiguity that a manual process allowed people to work around. Two employees may apply the same policy differently. A threshold may exist without clear ownership. An exception may be handled through an email rather than a documented procedure. A spreadsheet formula may continue producing a result even though nobody can fully explain the assumptions behind it.

Automation does not create those weaknesses. It reveals them.

A process that cannot be explained clearly is not ready to be automated responsibly.

From individual code cells to working applications

As the week progressed, the exercises moved beyond isolated commands. We began using the pieces together, and AI coding agents helped turn described ideas into functional applications.

I built a small browser-based HTML tool that allowed a user to upload a PDF, rearrange its pages into a preferred order, save the revised file, and print it. I also built a simple tic-tac-toe game and worked with APIs that could send a text message or initiate a phone call.

These were simple prototypes, not enterprise systems. That was precisely why they were useful: they showed me how quickly an idea could move from a description to something that worked.

My focus shifted from remembering every command to describing the desired result clearly, testing whether the application behaved as intended, and identifying what would have to change before a prototype could be trusted in a professional environment.

The PDF organizer made that difference especially visible. A tool may successfully rearrange pages, but a professional use case would raise additional questions. Was the original file preserved? Could a page be lost or duplicated? Was the final order validated? Would confidential information leave the organization’s approved environment? Who would review the result before relying on it?

The fact that an application works is important. It is not the same as proving that the application is reliable, controlled, or appropriate for a particular use.

The future of finance automation will not be shaped only by people who can write code. It will also be shaped by professionals who can explain the business logic clearly enough to make the code worth trusting.

Bringing Python into Excel made the connection practical

An optional Excel-based Python lesson brought the experience even closer to my accounting background. I installed the xlwings Lite add-in for Excel for the web and worked through examples involving Python functions in a workbook, ChatGPT in Excel, comparing or subtracting lists, and a final ledger-style example.

Excel remained the familiar interface, but Python expanded what could happen behind it. I was not being asked to abandon the tool accountants already use. I was learning how code and AI could extend it.

That distinction matters for finance transformation. New capabilities may become embedded in the spreadsheets, reporting tools, and workflows professionals already understand. The interface may remain familiar even when the process underneath it changes significantly.

Week 2 changed how I understood an AI workflow

In Week 1, I focused primarily on AI outputs: why a polished response still requires evidence and why professional judgment remains essential. Week 2 showed me what happens before and after that output.

An AI model may classify a transaction, summarize a document, or generate a narrative. But the surrounding workflow must still select and prepare the information, determine which rule applies, handle failures, place the result into a report or workbook, and route it to a person who can review it.

Variables give information a place to live. Data structures organize it. Functions make logic reusable. Control flow determines what happens next. APIs connect systems and services. Error handling addresses the expected path when it breaks. Coding agents can accelerate development, but they still depend on someone defining the business problem and testing whether the result is appropriate.

This changed my view of AI implementation. The model is important, but it is only one participant in the workflow. A useful AI application begins with understanding the process the AI is entering—not only with choosing a model or writing a prompt.

The CLEAR Logic Framework

By the end of the week, I noticed that the same questions kept returning—whether I was reviewing a Python function, a month-end-close activity, an API connection, or a small application. What is this process meant to accomplish? What information enters it? What rule is being applied? What happens outside the normal path? Who remains responsible?

Those questions became what I call the CLEAR Logic Framework: a review sequence informed by my CPA perspective for making business knowledge visible before a rule or process becomes part of an automated or AI-assisted workflow. It is not a programming methodology or a substitute for formal implementation standards. Its purpose is to help finance professionals explain what the technology is being asked to carry.

C — Clarify the purpose

Begin with the business objective. What is the process intended to accomplish? Who uses the result? What decision does it support? What is the consequence if the result is incomplete or wrong? Technology should serve the purpose of the process, not become the purpose itself.

L — Label the inputs

Identify and define the information entering the workflow and what each item represents. Where does it come from? Who owns it? Is it text, a date, an identifier, a rate, a balance, a category, or something else? Does it contain confidential or nonpublic information? A workflow cannot treat information correctly without understanding its business meaning.

E — Express the rule

State the rule in plain language. What calculation, classification, threshold, sequence, or decision should be applied? Which rule takes priority? What output should the process produce? If the rule cannot be explained clearly, it cannot be translated, tested, or reviewed clearly.

A — Assess exceptions

Consider what happens when reality does not follow the standard path. What if information is missing? What if two rules conflict? What if a value falls exactly on a boundary? What if the API or AI provider fails? What if the result looks unreasonable? A reliable workflow must be designed for more than the normal case.

R — Retain responsibility

Identify who owns the rule, reviews the output, approves changes, monitors performance, retains evidence, and remains accountable. Technology may execute the workflow. Responsibility for the workflow remains with the organization and the professionals who rely on its results.

A simple accounting example: automating a variance-review flag

For illustration, suppose a finance team wants to automate a monthly expense-variance flag. The example is simple, but it shows why the business rule must be clear before it becomes code.

• C — Clarify the purpose. The objective is to identify accounts that require investigation—not to explain the variance or approve the conclusion automatically.
• L — Label the inputs. Define the current-period amount, comparison amount, account, entity, period, approved threshold, and source owner. Confirm that the population is complete and the amounts are comparable.
• E — Express the rule. For example, flag an account only when the dollar difference exceeds $25,000 and the percentage change exceeds 10%. Define the formula, the order of the tests, and how positive and negative values are treated.
• A — Assess exceptions. Decide how to handle a zero comparison balance, a new account, a reclassification, a missing period, an acquisition, or a one-time transaction that makes the standard comparison misleading.
• R — Retain responsibility. Assign who investigates the flag, who approves the explanation, who may change the threshold, what evidence is retained, and how the rule is monitored over time.

The code can apply the threshold consistently. It cannot determine on its own whether the variance reflects an error, a timing difference, or a legitimate business event. That conclusion still requires context, evidence, and professional judgment.

What this means for finance transformation

Before this week, I often pictured finance transformation beginning with a system, an automation opportunity, or a faster-reporting goal. Python made me reverse that sequence.

Transformation begins earlier, when the organization makes the process visible enough to explain, test, and govern: its purpose, information, rules, dependencies, exceptions, controls, and ownership.

Once those elements are clear, Python, APIs, AI models, and coding agents can help the process operate faster and at greater scale. Without that clarity, technology may scale ambiguity and make the process more difficult to understand and more expensive to correct.

This is why accounting and finance professionals belong in AI and automation conversations. Our role is not necessarily to write every line of code. It is to define what the data represents, which business rules matter, where judgment is required, what could go wrong, what evidence should be retained, and who is accountable for the final result.

What changed for me

I began Week 2 expecting to learn a technical language. I ended it understanding AI applications—and my own role in them—differently.

I stopped seeing Python as a separate technical subject and started seeing it as a way of making the hidden logic inside finance processes explicit. I now see an AI model as one participant in a larger process shaped by data, code, business rules, systems, controls, and people.

The bootcamp also made the logic inside accounting more visible. We classify, validate, compare, calculate, apply thresholds, follow sequences, investigate exceptions, document conclusions, and design processes that other people must be able to follow.

I did not finish the bootcamp believing I had become a programmer. I finished it believing I could participate more intelligently in the design of AI-enabled finance processes—not because I knew every command, but because I could help explain the purpose, information, rules, exceptions, controls, and responsibility the commands were meant to carry.

The code may execute the rule. Finance professionals must still determine what the rule means.

Questions I’m still exploring

• How much programming knowledge does a finance professional need to participate meaningfully in AI and automation design?
• Which month-end-close activities are standardized enough to automate, and which remain too dependent on judgment and context?
• How should organizations document, approve, and version business rules that are embedded in code or generated with the help of an AI coding agent?
• As AI makes it easier to build tools, how do we ensure that development does not move faster than the organization's ability to understand and govern what it has created?

These questions do not make me less optimistic about AI. They make me more interested in helping finance teams design its use responsibly.

Companion practical resource

The companion guide turns CLEAR into a detailed worksheet and one-page readiness checklist covering purpose, inputs, rules, exceptions, human review, evidence, external connections, change ownership, and accountability.

Selected public sources and further reading

1. Columbia Business School Executive Education, “AI for Business & Finance Certificate Program.” Accessed August 3, 2026.
2. Python Software Foundation, “The Python Tutorial.” Accessed August 3, 2026.
3. xlwings, “xlwings Lite Documentation.” Accessed August 3, 2026.
4. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1 (July 2024).

Continue the Conversation

This article continues my exploration of how accounting and finance professionals can use emerging technologies while preserving business meaning, internal controls, evidence, and accountability.

About the author

Valentina DuPont, CPA is an accounting and finance professional with experience in financial reporting, month-end close, reconciliations, cash management, internal controls, audit support, and process improvement. Through the Knowledge Hub, she explores how professional judgment, governance, and emerging technologies intersect in modern finance.