AI-assisted coding has changed who can create financial software.
An accountant who would not describe themselves as a developer can now build a reconciliation script, invoice-processing tool, exception report, payment workflow, or close-management utility in days.
This is valuable. It also changes the control environment.
A script may begin as a personal experiment using synthetic data. Then it reads a live spreadsheet. A coworker starts relying on its output. It connects to an accounting platform. Eventually, it writes data or initiates an action.
At some point, the experiment becomes a financial system.
The risk is not that accountants are learning to code. The risk is that useful prototypes can become operational dependencies without visibly crossing a governance boundary.
Five levels of accountant-built automation
| Level | Capability | Minimum control |
|---|---|---|
| 0 · Experiment | Uses synthetic data locally | Basic documentation |
| 1 · Observer | Reads authorized production data | Access controls and logging |
| 2 · Advisor | Proposes classifications or actions | Validation and review workflow |
| 3 · Controlled writer | Updates staging or designated records | Approval, rollback, and reconciliation |
| 4 · Operational system | Executes recurring financial actions | Ownership, monitoring, testing, change control |
| 5 · Material system | Affects reporting, payments, or estimates | Formal governance and audit involvement |
The important transition is not from Excel to Python. It is from an individual productivity tool to a process other people depend on.
The citizen-development paradox
Accountants are often the people best positioned to automate accounting work. They know which exceptions matter, which documents support the decision, where policy requires judgment, and which actions cannot be easily reversed.
But domain expertise does not automatically provide version control, testing, access boundaries, monitoring, recovery procedures, documentation, or separation of duties.
This does not mean finance should stop building. It means organizations need a graduation path for useful prototypes.
The graduation gate
| Dimension | Question |
|---|---|
| Data | Does the workflow use confidential or regulated information? |
| Materiality | Could an error affect reporting or cash? |
| Reversibility | Can an incorrect action be safely undone? |
| Authority | Who approved the use case and its permissions? |
| Testing | Have happy paths, edge cases, and failure states been tested? |
| Evidence | Can the output be reconstructed? |
| Monitoring | Will someone know when the workflow fails? |
| Recovery | Is there a rollback or manual fallback? |
| Ownership | Who maintains it after the builder leaves? |
| Change control | How are modifications reviewed and released? |
Shadow mode before production
An accountant-built system should often begin by observing rather than acting. In shadow mode, it reads authorized inputs, produces a proposed result, records what it would have done, and compares its recommendation with the actual decision without modifying the source system.
This creates a testable transition from experiment to controlled use.
The leadership decision
Finance and IT should not force citizen development underground with an automatic prohibition. They should create a visible path through which useful prototypes can become governed systems.
How can accountants safely graduate useful automations instead of choosing between uncontrolled experimentation and no experimentation at all?
Source notes
- Deloitte, COSO Internal Controls and Generative AI. Summarizes risks involving rapid change, explainability, shadow AI, spreadsheets, interfaces, monitoring, and control design.
- Institute of Internal Auditors, Internal Control Over Generative AI. Addresses governance, risk management, and internal audit.