Inside Rippling Finance: Three principles for putting AI to work in accounting

AI is already changing how finance teams work. But in accounting, the question I keep coming back to is not simply, “Can AI do this faster?” The better question is: “Can AI do this in a way that is controlled, explainable, and audit-ready?”

That distinction matters. In finance, speed is only useful if the work remains complete, accurate, and defensible. A faster close does not help if the process cannot be reviewed. A faster reconciliation does not help if the team cannot explain what data was used. And an AI-generated answer does not help if an auditor can’t understand how the output was produced.

That is why I believe accounting teams need to approach AI with the same rigor we apply to the rest of the close, reporting, and controls environment.

Put simply: hope is not an internal control.

Individual productivity gains are valuable, but informal productivity gains in a corporate finance setting can quickly become dangerous. If a model touches financial data, supports a reconciliation, drafts a journal entry, or influences a close process, the team needs to know what happened, who reviewed it, and whether the output can be reproduced.

At Rippling, we use a practical governance framework for AI use cases that touch the general ledger. The framework is built around three principles:

1. Risk first, always.

2. Controls match the risk.

3. Prove what AI did.

Together, these principles help us move beyond experimentation and responsibly build AI into real finance workflows.

Principle 1: Risk first, always

The first principle is simple: no AI use case proceeds without an upfront risk assessment.

Not all AI use cases carry the same level of risk. Asking an AI assistant to summarize a policy document is very different from asking an autonomous workflow to prepare entries that touch the general ledger. A good governance model has to recognize that difference from the beginning.

At Rippling, we do not rely on a vague gut feel about whether something is risky. We use a structured formula to evaluate every proposal before design, procurement, or integration work begins:

Risk = impact × likelihood × autonomy × explainability

That formula forces us to ask practical questions early:

• What could go wrong if the output is incorrect?

• How likely is an error or misinterpretation?

• How much autonomy does the system have?

• Can we explain how the answer was generated?

• Would an auditor or controller be able to understand and test the process?

This upfront assessment helps us avoid one of the most common mistakes in AI adoption: treating every use case as if it belongs in the same category.

To make that more concrete, I think about AI use cases across four complexity buckets.

Bucket 1: Query

• The simplest starting point involves a single question with a direct conversational answer (e.g., 'Did all bills sync from BillPay for March?'). These low-complexity use cases provide simple outputs even when accessing important systems.

Bucket 2: Query + formatted output

• The AI is still assisting a human, but the answer now needs structure – a table, reconciliation, breakdown, or drill-down summary. One example would be a payroll register-to-GL reconciliation for a specific entity and month.

Bucket 3: Multi-source + automation

• These use cases join data across three or more systems, apply reconciliation logic, run on a schedule, or trigger alerts. They require orchestration, not just a chat-based answer.

Bucket 4: Custom build/agent

• The highest-complexity category: full applications, persistent workflows, autonomous agents, machine learning pipelines, or tools connected directly to systems through APIs. These use cases may take action, operate continuously, or require durable infrastructure.

My advice: do not start at bucket four.

Our strategy has been to start in bucket one and bucket two. Lower-risk workflows help us build internal trust, refine our data guardrails, and show auditors exactly how we review outputs before moving into more complex automation.

Principle 2: Controls match the risk

The second principle is that the level of control should match the level of risk.

This is where AI governance becomes more practical than theoretical. Once a use case has been scored and assigned a tier, that tier determines which guardrails and internal controls apply. This is not a one-size-fits-all model.

That matters because over-controlling low-risk work slows adoption, while under-controlling high-risk work creates exposure. The goal is not to throw controls at every problem indiscriminately. The goal is to map controls directly to workflow risk.

For accounting use cases, I focus on three areas where controls matter most.

Data completeness

Did the AI have access to the full data set required to answer the question or complete the task? If a reconciliation only looks at part of the population, the output may be polished but incomplete.

Data accuracy

Is the underlying source data correct, current, and appropriately reconciled? AI cannot compensate for bad data. It can only accelerate the consequences of using it.

Model configuration

How was the model instructed? What systems could it access? What constraints governed its output? What level of autonomy did it have?

Principle 3: Prove what AI did

The third principle may be the most important for accounting teams: every AI operation must be provable.

If an auditor or controller asks how a transaction was handled, the answer cannot be, “AI did it.” That is not evidence. It is not a control. And it is not enough to support a financial process.

We need an unalterable, read-only audit trail and change log for AI activity. We should be able to reconstruct what the model read, inferred, and wrote—every time.

That means capturing evidence such as:

• What source data the AI accessed

• What prompt or instruction was used

• What output the AI generated

• What changes were made to source systems

• Who reviewed or approved the output

• Whether the output can be reproduced

At the end of the day, I think auditors are looking for answers to three fundamental questions, regardless of whether a person or a machine performed the work:

• What’s the control?

• Who reviewed it?

• Can you reproduce the output?

AI does not remove the need for evidence. If anything, it increases the need for clear evidence because teams must be able to explain a process that can feel less visible than a traditional spreadsheet workflow.

That is also why parallel testing is so important. Before a model goes live in a production environment, it should run alongside the human workflow for a defined testing period. At Rippling, we use a mandatory minimum one-month parallel testing period before production deployment. That gives us time to validate accuracy, compare outputs, identify edge cases, and build confidence before relying on AI operationally.

The controls become stricter as the use case becomes more complex. A bucket one query might require basic review and source validation. A bucket three automated reconciliation might require documented logic, exception thresholds, review workflows, and evidence retention. A bucket four agent connected to an ERP needs a much more robust governance structure.

This also requires clear ownership. At Rippling, we created a formal accounting AI task force made up of leaders from controllership, financial systems, and SOX compliance. That group owns the operational lifecycle of the tools and helps ensure AI adoption is not scattered across the organization without accountability.

That is an important lesson for any finance leader: AI governance should not live only with IT, nor with individual users. Accounting, systems, compliance, and audit stakeholders all need a seat at the table.

What this means for the future of accounting

The promise of AI in accounting is not just a faster close. It’s a different way of working.

I believe the role of the accounting team will shift away from manual report preparation, data cleansing, and repetitive close tasks. More of our time should be spent on review, approval, exception handling, and strategic judgment.

In other words, we should eliminate the cognitive grunt work so that accountants can focus on being financial architects.

But the path to that future is not a leap straight into autonomous agents. It is a progression: start with lower-risk use cases, build trust, document controls, engage auditors early, and scale as the governance model matures.

AI in Accounting checklist

Download the checklist to launch AI in accounting without losing control.

The bottom line

AI can help finance teams move faster, but speed alone is not the goal. In accounting, the goal is controlled acceleration: faster work that is still complete, accurate, explainable, and audit-ready.

For me, that comes back to three principles:

1. Put risk first.

2. Match controls to the risk.

3. Prove what AI did.

That framework can turn AI from an informal productivity tool into a governed operating model—one that helps finance teams reduce manual work while preserving the trust, evidence, and rigor the function depends on.

Let Rippling Finance take care of the reconciliation work

See Rippling Finance