Outsourcing bookkeeping should remove repetitive work from the founder without transferring control of the company's money, systems, records, or decisions.

That distinction is the whole operating model.

A good outsourced setup lets the provider prepare and maintain the books while the company can still:

• see what changed;
• approve consequential actions;
• control money movement;
• recover records;
• remove access;
• review evidence; and
• end the relationship without rebuilding the finance stack from scratch.

You do not need the founder entering transactions every day to keep control. You need clear authority, limited access, independent review, and a reversible handoff.

The simplest way to design it is:

Define → configure → test → review → offboard

Start by defining what the provider may do

Do this before granting access.

Create a responsibility and authority matrix for every important task:

Do not treat “the bookkeeper owns this” as a sufficient answer.

The important questions are different:

• Can the provider prepare the transaction?
• Can they change the accounting record?
• Can they change master data such as a vendor bank account?
• Who independently reviews the work?
• Who authorizes a consequential adjustment?
• Who can release cash?

Those are different authorities and they do not need to live with the same person.

The general control principle is well established. NIST's current SP 800-171 Rev. 3 says organizations should identify duties that require separation and define access authorizations that support that separation. It also says access should be limited to what is necessary for assigned tasks and reviewed over time. NIST wrote that standard for protecting controlled unclassified information, not for startup bookkeeping, but the separation-of-duties and least-privilege principles are useful here. (NIST SP 800-171 Rev. 3)

Keep company ownership of the critical accounts

Your provider may operate inside the systems. The company should still own the relationship.

Keep company-controlled ownership of:

• the accounting subscription;
• the primary administrator account;
• company email domains;
• bank relationships;
• payment accounts;
• payroll-provider ownership;
• source documents;
• chart-of-accounts decisions;
• accounting-policy decisions;
• exports and retained records; and
• account-recovery methods.

Do not use a provider employee's personal email as the primary administrative identity for a critical finance system.

Do not let the only recovery method for a system live with the provider.

And do not make offboarding depend on the provider cooperating after the relationship ends.

The operational test is simple:

If this provider disappeared tomorrow, could the company still access the books, source records, bank accounts, users, audit history, and open work?

If the answer is no, the arrangement is too dependent on the vendor.

Give the provider the minimum access needed

“Never give a bookkeeper bank access” is too absolute.

Some workflows genuinely benefit from read-only bank feeds or controlled access. Some providers need direct access to the accounting system. The right question is not whether they have access. It is whether that access is scoped to the work and separated from authority they do not need.

Use:

• named user accounts rather than shared credentials;
• role-based permissions where the system supports them;
• multifactor authentication;
• the least privilege needed for the task;
• company-controlled administrator roles;
• periodic access review; and
• prompt removal when access is no longer needed.

QuickBooks Online's current role model illustrates why this matters. Intuit documents different roles with different capabilities, including bookkeeping/accounting roles and separate Bill Pay roles for bill approval, bill entry, and payment. The exact roles depend on the product, subscription, geography, and connected services, so check your current plan rather than assuming every account has the same options. (QuickBooks user roles)

Use the product's actual permissions to implement your control matrix.

Do not start with the software menu and let whatever roles happen to exist define your finance policy.

Separate preparation from approval and cash release

A bookkeeping provider may reasonably:

• collect source records;
• categorize transactions;
• prepare reconciliations;
• draft journal entries;
• enter bills;
• assemble schedules; and
• prepare the close.

That does not mean the same provider should automatically:

• create or change a vendor and release a payment;
• approve its own unusual journal entry;
• make a consequential prior-period change without review;
• decide a technical accounting treatment outside the agreed scope; or
• control the company's master credentials.

The most important separation is around money movement and consequential changes.

Where possible, separate:

1. preparation;
2. approval; and
3. cash release.

For example:

• the provider enters a vendor bill;
• an internal approver checks the invoice and business purpose;
• a person with payment authority releases the funds.

The exact division depends on the company and tools. The principle is that no one person should quietly create the obligation, approve it, and move the money without a compensating review.

Small teams need compensating controls, not imaginary segregation

A six-person startup may not have three finance employees.

That does not mean the control model is impossible.

It means you design compensating controls.

Examples:

• provider prepares, founder approves;
• provider categorizes, founder reviews a change report;
• provider reconciles, controller or external accountant reviews exceptions;
• provider enters bills, founder or department owner approves them;
• payment bank details trigger a separate approval;
• unusual or prior-period journal entries require explicit sign-off;
• bank alerts give the founder independent visibility;
• a monthly audit-log review catches unusual activity after the fact.

A compensating control does not remove risk. It makes the risk visible and independently reviewable when perfect role separation is impractical.

Do not claim a control exists because two names appear in a workflow. The reviewer needs enough evidence to actually challenge the preparer's work.

Do not use one universal approval threshold

There is no sensible single dollar threshold for every startup.

A $500 recurring software bill may be low risk. A $500 bank-detail change may be high risk. A $20,000 payment under an already approved contract can be routine. A $2,000 manual journal entry to a prior year may deserve controller review.

Define escalation around risk events, such as:

• new vendor;
• vendor bank-detail change;
• unusual or one-time expense;
• large payment relative to normal activity;
• manual journal entry;
• prior-period change;
• owner or related-party transaction;
• tax or payroll action;
• unsupported transaction;
• unusual revenue adjustment; or
• request to bypass the normal workflow.

The matrix can still include dollar thresholds where useful. Just do not confuse a dollar value with the control itself.

Test the first close before expanding authority

Do not grant the provider maximum access on day one and hope the process works.

Stage the handoff.

For the first close, inspect:

• bank and credit-card reconciliations;
• open reconciliation differences;
• unusual journal entries;
• source-document support;
• changes to vendor or account master data;
• unresolved questions;
• prior-period changes;
• close status;
• accounting-system audit history where available; and
• whether the founder or designated reviewer can independently reproduce the key evidence.

QuickBooks Online's current audit log is one example of a useful review mechanism. Intuit says it tracks financial transactions and other account activity, including who changed what, and the current documentation says audit-log events are available for two years. That is a product-specific feature and may change, so verify it against the system you actually use. (QuickBooks audit log)

The acceptance question is not:

Did the provider finish the close?

It is:

Can the company see the work, understand the exceptions, verify material changes, and identify who approved them?

Review access and evidence on a cadence

Access tends to expand quietly.

A provider gets temporary access to fix something. An old contractor stays active. Someone gets a broader accounting role because it was easier than configuring permissions properly.

Review the access register regularly.

Check:

• active users;
• administrator roles;
• accounting-system permissions;
• bank and card access;
• bill-pay roles;
• payroll access;
• expense-platform permissions;
• shared credentials;
• API and integration access;
• open support users;
• recovery email / phone ownership; and
• accounts that no longer need access.

Then review financial evidence:

• unreconciled accounts;
• unusual manual entries;
• prior-period changes;
• open exceptions;
• vendor-master changes;
• outstanding approvals; and
• access or workflow exceptions.

The frequency should reflect risk and activity. The important part is that it actually happens and leaves a record.

Write the exit before onboarding starts

Offboarding is where weak outsourcing setups become obvious.

Your engagement should define what happens when either side ends the relationship.

At minimum, specify:

• what records the provider must return or make accessible;
• file and export formats;
• how open work is handed off;
• how historical questions will be handled;
• who transfers any administrative role;
• when credentials and shared secrets are rotated;
• how connected apps are revoked;
• how bank or card access is removed;
• how payroll or bill-pay permissions are removed;
• who reviews the final audit/change history; and
• who confirms that the provider no longer has access.

QuickBooks currently documents that a primary or company admin can remove an accountant user, and that removal immediately ends that accountant's access to the company file. That is one product-specific offboarding step, not the whole offboarding process. (QuickBooks accountant removal)

Your provider may also have access to banks, cards, expense tools, payroll, cloud storage, email aliases, tax portals, billing systems, and shared credentials.

Offboarding is complete only when the whole access map has been reviewed.

Use one three-part control pack

The outsourcing arrangement becomes much easier to govern if you keep three working records.

1. Responsibility and Authority Matrix

Track:

• task;
• provider prepares?;
• provider can post/change?;
• reviewer;
• approver;
• cash authority;
• evidence required;
• escalation condition; and
• exception owner.

2. Access and Credential Register

Track:

• system;
• user;
• company / provider;
• role;
• permission;
• admin status;
• MFA status;
• access owner;
• granted date;
• last review date;
• revoke trigger;
• revoked date; and
• recovery owner.

Do not put passwords in this workbook.

3. Onboarding, First-Close, and Offboarding Checklist

Track:

• requirement;
• owner;
• due date;
• evidence;
• status;
• exception;
• acceptance; and
• revocation / handoff result.

The records matter because governance should survive a personnel change. It should not live only in the founder's memory or in a Slack conversation with the bookkeeper.

Keep monthly deliverables separate from access controls

This page is about control.

It should not also become a giant list of what a bookkeeper should deliver each month.

Those are different reader jobs.

Once access and authority are properly designed, the next question is:

What exactly should the provider deliver each month, what proves the work is complete, and what is outside scope?

That belongs in the monthly bookkeeping delivery specification rather than inside the access-control article.

For the detailed accounting close itself, use Chore's month-end close checklist.

For the broader decision about which finance functions to outsource, use the existing guide to outsourcing startup financial management.

Where Chore fits

The control model should apply to Chore too.

Chore's current bookkeeping product page describes bookkeeping and finance support, connected financial accounts, historical data onboarding, reconciliations, and recurring monthly work. That makes it commercially relevant to this question, but it does not prove that Chore uses the exact access, approval, or offboarding process described in this article. (Chore bookkeeping and finance)

If you are evaluating Chore or any other provider, ask for the actual current answers to these questions:

• What access will your team need?
• Which roles will you receive in each system?
• Who retains primary admin?
• Can you create or change vendors?
• Can you approve payments?
• Can you release cash?
• How are journal entries reviewed?
• How are historical changes reviewed?
• How are credentials handled?
• What audit/change evidence is available?
• What records remain company-owned?
• What exactly happens at offboarding?

The provider is not the control.

The control is the system that lets the company delegate the work while retaining authority, visibility, evidence, and the ability to reverse the handoff.