The Accounting Team of Two

For decades, scaling a startup finance function meant scaling your accounting team and your ERP spend linearly with revenue.

‍

Every accounting system assumed that growth meant headcount, and plenty of them charged you for it through seat-based licensing. More volume, hire a staff accountant. New geography, add an entity and another accountant.

‍

The part of a controls framework that actually requires people is much narrower: proof that whoever prepared a transaction isn't whoever approved it. That takes two people, not a department.

‍

DualEntry is built for that pair, a preparer and an approver, each running a fleet of agents beneath them. In larger finance teams, the same structure can be repeated across entities and functions. Agents absorb the volume, so two people can spend their time on judgment rather than on the work that used to take eight.

‍

Slash, a fintech at $300M ARR, already runs finance with a team of two. We intend to carry that structure all the way to your IPO. Nothing in the regulations prevents it. Supralinear growth, revenue rising faster than headcount, is a software problem before it is an accounting one.

Why two is the number

Every controls framework a growing company runs into asks for the same thing:

‍

COSO's 2013 framework builds segregation of duties into Principle 10, and where it isn't practical, asks management to develop alternative control activities instead.

‍‍

SOX 302 and 404 turn that into a certification and an assertion for registrants, tested by the auditor under PCAOB AS 2201.

‍

AS 2401 and AICPA AU-C 240 send auditors straight at your journal entry population, because management sits in a unique position to override controls that otherwise look effective.

‍‍

GAO's Green Book spells out the split for federal entities, separating authorization, processing and recording, review, and custody so no one person controls all key aspects of a transaction.

‍

And 2 CFR 200.303 requires anyone spending a federal award to establish and maintain effective internal control, pointing at the Green Book and COSO as the benchmarks.

‍

None of them specifies a headcount. They specify a boundary. Every hire beyond the pair is there to scale output, and output is what agents supply.

Who sits in each seat

The pair changes shape as the company grows. The boundary does not: two distinct identities on every transaction, and a record of who did what that nobody can edit afterward.

‍

Early. A bookkeeper or staff accountant prepares, and the founder-CEO approves. The preparer can be outsourced: a bookkeeper, a fractional controller, or a firm on a monthly engagement. For many companies that is the better answer, because it buys audit and close experience you could not yet justify as a full-time hire.

‍

The setup survives an audit, with three conditions. Bank statements route to the approver before the preparer touches them, the approver looks at general ledger detail, not just the P&L, and the review leaves evidence of what was examined. A CEO who signs whatever is put in front of them is not an approver, and it takes an auditor one question to find that out: what did you look at last month? Agents make the answer a good one. It puts the general ledger detail and the questions a controller would ask in front of the CEO, so the signature reflects an actual review.

‍

Growing. The accountant prepares and a controller approves. The preparer is often an agency or an offshore team, which works as long as the controller holds the authority and the audit trail shows it. The executive now leaves the control path, and that is the point: the person with the most authority to override a control should not be the one approving.

‍

Mature. A formal preparer and approver pair sits inside accounting, with the CFO on material judgments only. The pattern also splits by subfunction: AR and AP each run their own boundary, often with several preparers to one approver, and each closes its piece independently.

When the boundary becomes mandatory

Your first audit tests your actual journal entry process. An approval workflow that lives in someone's memory does not survive that, and you cannot install a control environment retroactively or backfill the evidence. Companies that wait until a banker calls can spend two quarters or more in high-stakes, painful remediation.

‍

Any material liquidity event, like an acquisition or an IPO, sets a hard date for compliant books, and that date reaches backward. Under Regulation S-X, a standard domestic registrant files audited balance sheets for the two most recent fiscal years and audited income and cash flow statements for the three most recent. Emerging growth companies and smaller reporting companies can file two years instead. Section 404 reporting on internal control comes later, starting with the second annual report after the IPO. The financial statements do not wait: the books you close today may be the ones in your registration statement.

‍

Something other than revenue usually forces the change first, and most often it is entity count. The first foreign subsidiary brings functional currency, intercompany eliminations, and local statutory filings, and it arrives whether or not you have a second person in finance. Debt covenants requiring audited statements do the same. So does the Single Audit if you take federal money: under 2 CFR 200.501, any entity expending $1,000,000 or more in federal awards in a fiscal year has to obtain one.

‍

Revenue matters less as a threshold than as a proxy for what arrives with it. Somewhere between $10M and $25M, most companies pick up an audit as a condition of a financing round, a board with independent directors who want to see the reconciliations behind the numbers, and enough transaction volume that one person can no longer look at everything before it posts.

What breaks in different businesses

SaaS businesses break on revenue recognition. A mid-term upgrade, a co-term renewal, and a usage overage each rewrite the schedule under ASC 606, and that work scales with contract count. Agents build the schedules from the contract terms. The approver decides the parts that are actually judgment: how to estimate standalone selling price, and whether a modification is a separate contract, a prospective change, or a cumulative catch-up.

‍

Rollups and funds break on structure. A PE-backed rollup inherits a chart of accounts from every company it buys, and until those are mapped to one structure, consolidated reporting is a spreadsheet exercise. A fund or family office has the opposite problem: the entities were never operating companies, they are SPVs, holdcos, management companies, and trusts, and the work is allocating across funds and SPVs, calculating management fees and carry, and maintaining capital accounts and the waterfall. Agents map the accounts, run the allocations, and draft the eliminations. The approver signs off on the eliminations, valuations, and allocations.

‍

Multi-location services businesses break on bank reconciliation. Each site deposits on its own schedule into its own account, so the close means tying dozens of separate deposit streams back to what the POS or booking system says was collected. On Track Storage runs 43 locations across 6 entities with a one-person accounting department. Agents suggest the matches. The preparer reviews and confirms. The approver decides which ones are timing and which ones mean a site has a problem.

‍

Inventory businesses break on landed cost (ASC 330). A container arrives and the freight, duty, and brokerage on it have to be capitalized to the unit level before anything ships, or margin is wrong on every order that touches those units. Then the cycle count comes back short and someone has to say whether that is a receiving error, theft, or stock that was never going to sell. Agents allocate landed cost to units and reconcile the count. The approver rules on the shortage and separately decides whether slow-moving stock needs an NRV write-down.

Compliance first, then automation

We built the controls first. The human approver is a constraint in the data model, enforced below the interface, so it holds no matter what writes to the ledger. The immutability guard sits in the persistence layer, which means the gate is on every write path, not on every screen. Approval policy covers integration-created transactions the same as manual ones.

‍

In most systems the workflow only fires on manual entry, so a bill arriving from a connected AP tool posts without review. Period locks, role-based permissions that block self-approval, and tamper-proof version history all shipped before the first agent did. Permissions are identical across the UI, the API, the CLI, and MCP, so no surface widens anyone's scope. A control that lives in the interface only applies to people using the interface, and an agent is not using the interface.

‍

Then automation, and the rule is to use the cheapest thing that works. Deterministic rules handle anything with a stable answer: recurring accruals, bank fee coding, allocation schedules. Machine learning covers categorization at volume, where the pattern is learnable but nobody can write the rule. LLMs read the unstructured input, meaning bills, contracts, and remittance advice. Skills and tools encode procedures your team already runs. Agents take the multi-step work, chasing an exception, pulling the support, and proposing the entry. Scheduled agents run with human-in-the-loop approval against the close calendar. Anything an agent can do, a human can do by hand.

‍

All of it lands in the same place. A proposed entry sits in an approval queue with a named preparer, and the agent that prepared it appears in the audit trail under its own identity. The approval is the posting event, which means a human hand is on every entry in the ledger even when a machine did the work.

‍

Because approval is the posting event, the ledger is current as of the last approval, and you report straight out of it. The numbers are never stale, so you see a problem while it is still small and act before it compounds. 

Getting there from the system you run today

Where you start decides the work. Coming from QuickBooks, the migration is a cleanup, because the controls you need were never there to migrate. Coming from NetSuite, it is a port, because they were. Either way, the first thing to get right is the chart of accounts, because it decides what you can automate.

A chart of accounts you can automate against

The chart of accounts you set up before you had a controller is the one your first serious auditor inherits. Take 400 accounts where 300 of them should have been dimensions, so Marketing Spend UK Paid is its own account. There is no pattern for a rule to find and no way to roll up marketing across entities without a spreadsheet.

‍

Every close becomes manual remapping, and every one of those closes is a period someone will eventually examine. Collapse those 300 accounts into dimensions and the reverse is true: one Marketing account, tagged by entity and region, is a pattern a rule can find, and a rule that runs is a close that does not wait on a person.

Graduating from QuickBooks

For a lot of companies the trigger to graduate is blunt: auditors do not treat QuickBooks as IPO-ready. QBO permits choices a control environment cannot, including editing a posted transaction, reopening a closed period, and one login that prepares, approves, and reconciles. Companies that grew up on it often have no period lock discipline and no approval trail to migrate.

‍

Missing controls make the migration a cleanup rather than a port. We ensure accuracy first: we bring transaction-level history rather than trial balances, and we tie out against your source system before anything else happens, so prior periods stay queryable when an auditor asks and the numbers match what you already reported. Design second: once the data is accurate, the CPA implementation team helps you rebuild the chart of accounts, move what should be dimensions out of the account list, and set your approval thresholds and close calendar. Reverse the order and you get an elegant structure holding numbers nobody can tie out.

‍

Every implementation is led by an accountant or a CPA. The people who design your chart of accounts, dimensions, entity structure, approval thresholds, and close calendar have sat through audits, run diligence, and prepared books for public companies, and they give you advice specific to your business instead of a template. They also stay on your account after go-live. The person who advised on the setup is the person who supports it afterward, which is the only arrangement that reliably produces advice that holds up years later.

Migrating from NetSuite

NetSuite customers already have period locks, approval routing, segregation of duties, and an audit trail their auditors accept. We are not asking you to give any of it up, which is what makes this migration a port rather than a cleanup.

‍

What changes is that in DualEntry the AI was designed into the ledger instead of attached to it. Human-in-the-loop approval is enforced in the data model, so it applies to an agent the same way it applies to a person. And an agent that lives inside the ERP works from the real ledger, with the same permissions a user in that role would have: the transaction, its history, the related contract, the dimensional structure, how the same thing was treated last period.

‍

An AR agent sees AR. It does not touch AP. An external agent working through an integration sees only what the integration hands it, and no API exports enough context for it to reason the way an accountant would. That is the difference between an agent that proposes the right entry and one that proposes a plausible entry.

Design the finance org you actually want

The goal was never a bigger accounting team. It was compliant books you can trust, closed every quarter in every entity. Accounting never required headcount to grow with revenue. The software did, and companies quietly reorganized around the limitations of the system they bought.

‍

Put the one boundary the frameworks require into the ledger itself, give agents to the preparer and the approver, and the finance org is yours to design.

‍

Getting here used to mean a six-figure implementation. Most vendors make you pay first, in time, in dollars, or both, and you find out whether the product works two to eight months later.

‍

We do it the other way around. We migrate your real financial data into a working sandbox and let you tie out the balances at no cost, because you should judge us on your messy reality, not on a demo dataset. We'd rather help you close your books than ask you to open your wallet.