QuickBooks Online Advanced Custom Role Permissions: A CPA’s Guide to Internal Controls
Why Custom Roles Matter — The Internal Controls Problem
Walk into any small business that has been on QuickBooks Online for more than two years and ask who can pay a bill. The answer is almost always “everyone with a login,”. And the login list almost always includes someone who left the company eighteen months ago. That is the internal controls problem QBO Advanced custom roles exist to fix.
The risk isn’t theoretical. The most common small business fraud pattern we see is a bookkeeper who enters a fake vendor, pays that vendor for a year, and then writes off the receivable when the books get reviewed. The fraud succeeds because the same person is creating the vendor, recording the bill, and approving the payment. In QBO Plus that is unavoidable. The roles aren’t detailed enough to split those three actions. In QBO Advanced, splitting them takes about ten minutes and stops the most common attack vector before it starts.
Even outside fraud, the controls problem shows up in everyday mistakes. A sales coordinator who can edit invoices accidentally voids a $40,000 invoice to a customer who already paid. A part-time bookkeeper renames an income account in the middle of a quarter, breaking every report that compares this year to last. A junior employee on their second day deletes a vendor because they thought it was a duplicate. None of these are malicious. All of them are expensive. All of them are preventable with a role that doesn’t give the user the button they don’t need.
The AICPA publishes a Statement on Standards for Attestation Engagements (SSAE 18) that describes the level of internal controls a public company expects from its vendors and partners. Private companies aren’t legally required to meet that standard, but lenders, insurance carriers, and acquirers increasingly ask for it during due diligence. A QBO Advanced file with documented custom roles and a quarterly access review answers most of what those parties want to see. A QBO Plus file with everyone as an admin does not.
One more reason to take this seriously: the cost of fixing a controls failure after the fact is always higher than the cost of preventing it. We have spent two weeks unwinding a $14,000 vendor fraud at a client who waved off the custom role conversation a year earlier. The cost of unwinding it (forensic work, restated financials, insurance claim, legal review) was about $22,000. The cost of setting up the roles correctly the first time was about three hours of our time.
The Custom Role Builder: How It Works
The role builder lives at Settings → Manage users → Roles. You’ll see two columns. The left column lists predefined roles that ship with the file (Standard all access, Standard limited customers and sales, Standard limited vendors and purchases, Reports only, Time tracking only). The right column is empty when you start. That is where custom roles go.
To build a role, click Add role. You give it a name, a description, and then walk through a tabbed interface that exposes permissions by area: Sales, Expenses, Banking, Payroll, Reports, Inventory, Employees, Time tracking, and Accounting. Each tab lists the entities in that area (Invoices, Bills, Checks, Journal Entries, etc.) and for each entity you can grant View, Create, Edit, Delete, Print, or Share independently. The combination of toggles is what produces the role’s actual access.
Scope filters live below the permission toggles. If your file has classes turned on, you can restrict a role to a class or a list of classes. Same for locations. Same for customers (sales rep roles, for example, can be locked to their own customer list). The scope is multiplied against the permission. A Sales Rep role with Edit on Invoices and a scope of Customer A and Customer B can edit invoices for those two customers and nothing else. The same role given Edit on Invoices but no customer scope can edit every invoice in the file. The scope is the difference between a useful sales rep role and a sales rep who can edit anyone’s data.
Save and the role goes into the right column. Now you assign it. Back to Manage users, click the user, change their role to the new custom role, save. The change takes effect on the user’s next login. There is no overnight wait or sync delay.
The access summary view is the underused part of the builder. When you click a user, the right panel shows an “Access summary”. That translates the role back into plain English: “Can create invoices. Cannot delete invoices. Can view reports in the Sales category. Cannot view payroll.” That summary is exactly what we attach to the year-end working papers when we document a client’s control environment. It is the printable record of who could do what during the period under review.
One thing the role builder does not do: it does not let you build a role by copying from a starting role and modifying. You start from a blank slate or from one of the predefined templates. We keep a one-page reference document for each client listing the eight or so custom roles we build, so when we set up a new file we work from that reference rather than trying to remember every toggle.
Eight Custom Roles We Configure for Every QBO Advanced Client
Here are the eight roles we build for every Advanced client, along with the permissions that define each. The dollar thresholds in some of these are paired with QBO Advanced workflows that enforce approval routing.
1. AP Clerk. Create and Edit on Bills and Vendor records. View on Chart of Accounts. View on Banking (so they can see paid status). Nothing else. No Pay Bills, no Checks, no Journal Entries, no Sales access, no Payroll, no Reports outside of AP Aging and Bill List. This role can enter a bill but cannot pay one.
2. AP Approver. View on Bills. Create on Bill Payments. Create and Edit on Checks. View only on Vendor records. Nothing on Sales. Limited Reports (AP Aging, Bill Payment List, Vendor Balance). This role can pay a bill that the AP Clerk has already entered, but cannot enter one. A workflow we always pair with this role routes bill payments over $5,000 to the owner for a second sign-off before they post.
3. AR Clerk. Create and Edit on Invoices, Sales Receipts, and Customer records. Create on Received Payments. View on Banking. View on AR-related Reports. No Edit on credit memos above $500 (the workflow routes those for approval). No access to Expenses, Payroll, or company settings.
4. Bookkeeper. Create and View on most transactions. Create and Edit on Journal Entries (but the workflow routes any JE over $1,000 for owner approval). View on Payroll (so they can record payroll JEs from an outside payroll service). View on all Reports. No User Management. No Company Settings. No Chart of Accounts modification rights. This role is what we usually assign to ourselves or to an external bookkeeper we are working alongside.
5. CFO View. Read-only on everything. Full access to Reports. No Create, Edit, or Delete anywhere in the file. The CFO can see every transaction, run any report, and export anything they need, but cannot change the books. This protects the integrity of the file from well-meaning executive edits that would otherwise show up in the audit log without explanation.
6. Project Manager. View on Projects and Estimates. Create and Edit on Time Entries scoped to specific projects. View on Project Profitability reports for their projects only. No access to other projects. No Banking, no Payroll, no chart of accounts. This is the role for non-finance staff who need to track project budgets against actuals.
7. Sales Rep. Create and Edit on Invoices and Customer records scoped to their assigned customer list. View on AR Aging and Customer Balance for their customers only. No access to other customers. No Expense, Banking, or Payroll access. The customer scope is the critical piece. Without it, every sales rep can see every customer’s payment history, which is usually not what the business wants.
8. Owner. Full Company Admin. The only user with this role is the business owner or the master admin successor. This role can change other users’. Roles, change the subscription, and transfer the master admin to someone else. We keep this role limited to exactly one or two people. Every other user, including the CFO and the bookkeeper, runs on a custom role.
This eight-role pattern fits about 80% of the small businesses we serve. The exceptions are usually industry-specific: a construction client might add a Job Cost Reviewer role, a non-profit might add a Grant Reporter role, an e-commerce client might add a Returns Specialist role. The pattern is the same: define the smallest set of permissions the job actually needs, scope by class or location or customer where it matters, document the role in writing, review it quarterly.
Detailed Permissions: What QBO Advanced Actually Lets You Restrict
The permission grid is wider than most people expect. Inside Sales, for example, you can grant Create on Invoices but deny Delete, deny Send, and deny the ability to issue Credit Memos above a defined threshold. Inside Expenses, you can grant Create on Bills but deny Pay Bills, deny Bill Reminders, and deny the ability to edit a closed period. Inside Banking, you can grant View on registers but deny Reconcile and deny the ability to modify reconciled transactions.
The permission that gets the least attention and matters the most is “modify closed period.” A closed period in QBO is the date range before which transactions cannot be edited without a password. Granting a user the right to override that password effectively lets them rewrite history. We deny this permission to every role except the Owner and the external CPA firm. If a bookkeeper needs to make a correction in a closed period, the right answer is a journal entry in the current period that references the prior period, not a backdated edit. The audit trail stays clean.
Another high-impact permission: chart of accounts modification. QBO lets you grant View on chart of accounts without granting Create or Edit. The vast majority of users in any file need View (to categorize transactions) and not Edit. Restricting Edit to the Bookkeeper and Owner prevents the most common cause of broken comparative reports: a user who renames an account mid-year without realizing reports look back at the prior name.
The Reports permission area deserves its own attention. You can grant a user access to specific report categories (Sales, Expenses, AP, AR, Banking, Inventory, Payroll, etc.) and deny others. A Sales Rep who can see AR Aging but cannot see Profit and Loss is one toggle away. A Project Manager who can see Project Profitability for their projects but cannot see overall company P&L is the same toggle pattern. We use this aggressively. Most users do not need P&L access. Restricting it answers two questions at once: it prevents accidental sharing of sensitive numbers, and it removes the ability to compare individual project margins against the company-wide average without leadership context.
Scope filters (class, location, customer) live underneath the permission toggles and multiply against them. A role with full Sales access and no scope can see everything. A role with full Sales access and a scope of Location A can see everything in Location A. A role with View-only Sales access and a scope of Customer X can see invoices for Customer X but cannot create or edit them. The scope and the permission together produce the actual access. We document both sides in the role definition.
One useful pattern with scope: territory-based sales roles. If your sales team is split by region, build a role per region with the appropriate scope. A Western Sales Rep role scoped to Western customers, an Eastern Sales Rep role scoped to Eastern customers. Each rep gets the role for their region. When a rep changes regions, you change their role. The customer list doesn’t have to move.
Auditing Roles and Catching Permission Drift
Permission drift is what happens when roles change over time without anyone tracking the changes. A bookkeeper leaves, the replacement gets a slightly expanded version of the same role, then someone adds a permission to handle a one-off task and never removes it. Six months later the role looks nothing like the original, and nobody remembers why.
The defense against drift is a quarterly access review. The mechanics are simple. Once a quarter, the controller or owner exports a list of every active user, their assigned role, and the access summary for that role. The list goes to each user’s manager with a single question: is this access still appropriate for this person’s job today? The manager checks yes or flags a change. The signed list goes into a folder. That is the whole process. About an hour for a 20-user file.
The QBO audit log is the other piece of the audit. Every change in QBO is logged with the user, timestamp and before/after values. Once a quarter we export the audit log for the period and look for two things: actions performed by users whose role shouldn’t have allowed them (which means someone temporarily changed a role and forgot to change it back), and actions performed near separations (which can flag a departing employee who tried to clean up evidence on the way out). The first is more common than the second, but you catch both.
One trick: when you build a role, save the role definition as a printed PDF and keep it with the client’s working papers. Six months later when the role looks different, you have the original to diff against. Without it, you are working from memory, and memory loses every time.
For clients on the larger side, we set up a workflow that emails the controller whenever a role is modified. The workflow is just an audit log filter, and the email is the trigger. Any role change generates an email. The controller reviews and either accepts or asks for the change to be reverted. That feedback loop catches drift on the day it happens rather than at the next quarterly review.
Permission drift gets worse during personnel transitions. A user who is on their way out should not be modifying roles on the way. A user who is just promoted should not be granted expanded permissions on day one before the access review confirms what’s appropriate. Both patterns are easy to enforce: lock the role builder to the owner and the controller only, and require a written request and approval before any role change. The request itself is documentation.
What Custom Roles Can’t Do (Field-Level and Row-Level Limits)
The role builder is wide but not infinitely deep. Two limits show up in almost every implementation we do.
The first is field-level restriction. You cannot grant a user the ability to see an invoice but hide a specific field on that invoice. If a user can see the invoice, they see the customer’s email address, the memo field, the internal notes, and the line item descriptions. If you have sensitive data in a custom field, the only options are to restrict the entire invoice or to move the sensitive data out of QBO. There is no in-between. The same limit applies to vendor records: you cannot hide a vendor’s bank account number from a user who can see the vendor record.
The second is row-level restriction beyond what the scope filters cover. You can scope a role to a class, location, or customer list, but you cannot scope to “all invoices over $10,000”. Or “all bills marked as confidential”. Or “everything except the owner’s salary.” Row-level filtering is limited to the three built-in dimensions. If your security need is “the AR clerk can see most invoices but not the ones to our largest customer,”. You have to model it with the scope filter (excluding that customer’s role from their list), which works but takes maintenance.
Payroll is where the limits hurt the most. The Payroll permission area in QBO is essentially binary: a user either has access to payroll or they don’t. There is no way to give a user access to part of payroll (say, the ability to enter time but not view rates of pay) without giving them more access than you wanted. The workaround is to use a separate payroll system for sensitive cases and keep QBO Payroll for the simpler scenarios.
Multi-entity files are another limit. QBO does not natively support multi-entity consolidation. If you have three legal entities, you have three QBO files, and each file has its own role assignments. A user who needs access to all three needs three separate role assignments, and there is no way to manage them centrally. This is one of the reasons NetSuite and Sage Intacct still win the bake-off for businesses with multiple entities. The role and permission model spans the entity boundary.
Custom fields are partially restricted. You can hide custom fields from specific roles if you mark them as internal-only, but the granularity is limited. Most custom fields show up to anyone who can see the parent record. If you need to hide compensation data, contractor pay rates, or sensitive client information, custom fields are not the right place to put them.
The honest answer: QBO Advanced custom roles cover the access control needs of about 85% of small businesses. The 15% that need field-level or row-level restrictions beyond what the scope filters provide either accept the gap, use workflow approvals to compensate, or move to a higher-tier system. We have helped clients in both directions. The conversation starts with what the actual risk is and what the cost of additional control would be, and ends with either a workflow-based compensating control or a recommendation to look at a different platform.
Frequently Asked Questions
What’s the difference between QBO Advanced custom roles and QBO Plus’s fixed roles?
Both versions of QuickBooks Online give you a user management screen, but the underlying permission model is completely different. In QuickBooks Online Plus, you choose from a small set of fixed roles: Standard user (with sub-templates like “All access,” “Limited customers and sales,” “Limited vendors and purchases,”. And “None”), Company admin, Reports only, and Time tracking only. The choices look detailed at first, but once you click into each template you are stuck with a bundle. If you want a user who can record bills and pay them but who cannot see payroll, you cannot get there with Plus’s templates. The closest option grants either too much or too little.
QBO Advanced replaces that fixed list with a custom role builder. You start from a blank role or from a predefined template (Standard all access, Standard limited customers and sales, Standard limited vendors and purchases, and a few others) and then check or uncheck individual permissions across the application. Permissions are grouped by area: Sales, Expenses, Banking, Payroll, Reports, Inventory, Employees, Time tracking, and Accounting. Inside each group, you can grant View only, Create, Edit, Delete, Print, or Share, depending on the entity. A custom role can also be scoped by location, class, or customer if those dimensions are turned on in your file.
Here is the practical difference. In Plus, our typical client says, “I want my AP clerk to enter bills but I don’t want them to see customer payments or payroll.” With Plus, you cannot do that cleanly. The Standard limited vendors template lets them see vendor data but also exposes parts of the file you didn’t want them in, and there is no way to surgically remove the leaks. In Advanced, you build an AP Clerk role, grant Create and Edit on Bills, View on Vendors, deny everything in Sales, deny Payroll entirely, and limit Reports to AP-related reports. The result is a user who sees only what their job needs.
Another concrete gap: Plus has no way to separate the person who enters a bill from the person who approves it. The same user who has “Limited vendors and purchases”. Can record a $50,000 bill and pay it without anyone in the system seeing it before the funds leave. That violates the most basic AICPA internal controls standard. Advanced solves it with two roles: an AP Clerk who can create bills but not pay them, and an AP Approver who can pay bills but not create them. The same person cannot do both with a single login.
The license cost difference matters too. At the time we are writing this, QBO Plus is around $99 a month and Advanced is around $235 a month. That delta of roughly $136 a month or $1,632 a year buys you the custom role engine, the workflow engine, custom reports with the Reports Builder, batch invoicing, and a few other things. For a business with five or more users, the role builder alone often justifies the upgrade. Without it, you either let people see things they should not, or you spend hours each month manually limiting what they touch, or you pay a CPA to fix the resulting mess at year-end.
One more difference people miss: audit log behavior. In Plus, the audit log records actions but it is harder to tie an action to a tightly scoped responsibility because the roles are bundled. In Advanced, when an AP Clerk creates a bill, you can see in the audit log that the user with the AP Clerk role created it, and because the role’s scope is narrow, the trail is meaningful. We rely on that distinction during year-end work when we are trying to figure out who touched what and when.
The short version: Plus’s roles are good enough for a two- or three-person shop where everyone is in everything anyway. The moment you have five users or you have a person you don’t fully trust with the entire file (a part-time bookkeeper, a temp, a new hire on probation, a sales rep who only needs to see their own customers), you need Advanced. The cost step-up pays for itself the first time the custom roles catch an error or block a fraud attempt that Plus would have allowed.
A pattern we run into often when migrating clients from Plus to Advanced: the existing Plus setup has everyone as an admin, “because it was easier.” Easier on day one, painful for the next three years. The first thing we do on a Plus-to-Advanced migration is run an export of who can do what in the current file. The list is almost always longer than the owner remembers. Three former employees still active. A summer intern from two years ago. A consultant whose engagement ended in 2024. Every one of those is a live attack surface. The Advanced custom role builder gives you the tools to fix the inventory and keep it clean from now on.
One more underrated difference: Advanced’s role builder lets you write a description for each role. That description is shared metadata. If we build an AP Clerk role and write “Can create bills up to $5,000. Cannot pay. Routed for approval via workflow over $5,000”. In the description, every future admin who looks at the role knows what it was meant to do. Plus has no equivalent. The fixed roles in Plus carry generic Intuit-written descriptions that don’t tell you anything about how your business decided to use them.
The licensing nuance matters for multi-entity owners too. Each QBO file requires its own subscription. If you run three businesses through three QBO files, you pay three Advanced subscriptions to get the custom role builder in all three. Some clients try to save money by keeping one or two entities on Plus and only the largest on Advanced. That works financially but it means the smaller entities run with the bundled-role compromise. We usually push for Advanced across the board once total revenue across the entities crosses $2M and there are more than three users in any single file.
How should I design custom roles for proper segregation of duties?
Segregation of duties is the rule that says one person should not be able to start and finish a single financial transaction. It is the single most-cited internal control idea in AICPA guidance, and it is the one most small businesses skip because they think they don’t have enough staff to enforce it. In QBO Advanced, the custom role builder makes the enforcement easier than you would expect, even with three or four people.
Start by writing down the four basic functions every transaction touches: authorization (who approves it), recording (who enters it in the books), custody (who has access to the asset, usually cash or inventory), and reconciliation (who checks that the records match reality). The goal is to keep at least two of these four in different hands. If the same person authorizes a payment, records it, and then reconciles the bank statement, there is no one watching.
Applied to QBO Advanced, the cleanest split is between the AP Clerk and the AP Approver. The AP Clerk has Create and Edit on Bills and Vendors, View on the chart of accounts, and no access to Banking or Payroll. The AP Approver has View on Bills, Create on Bill Payments (which is the act of paying), Create and Edit on Checks, and View only on Vendors. The clerk enters the bill. The approver pays it. Neither one can do both. If you have a third person involved (often the bookkeeper or the CFO), they get the role with bank reconciliation rights and no authorization or recording rights. That is the three-way split the AICPA wants to see.
On the AR side, the equivalent split is AR Clerk and AR Approver, though most small businesses don’t enforce it as tightly because the fraud risk on the AR side is different. Where it really matters on AR is the credit memo. A user who can both invoice a customer and issue a credit memo against that invoice can hide a stolen payment by writing it off. We always split that authority: the AR Clerk creates invoices and records payments, and only the controller or owner can issue credit memos above a threshold. We enforce the threshold with a workflow that routes credit memos over $500 to the owner for approval before they post.
Bank reconciliation is its own role. Whoever reconciles the bank account each month should not be the same person who records cash receipts or writes checks. In a three-person shop, the AR clerk handles cash receipts, the AP clerk handles disbursements, and the owner or external bookkeeper handles the reconciliation. In QBO Advanced, you build a Reconciler role that has View on Banking and Create on the Reconciliation page, but nothing on Sales or Expenses. The reconciler can find errors but cannot create or hide them.
Payroll is the function where segregation breaks down most often. In most small businesses, one person processes payroll, approves the payroll register, and submits it to the bank for payment. That is a fraud-and-error vector wide enough to drive a truck through. The right split in QBO Advanced Payroll: a Payroll Processor role with Create and Edit on payroll runs and View on employee setup, and a Payroll Approver role (usually the owner or CFO) with Approve and Submit rights but no edit access to the underlying timesheets. The processor enters hours and rates. The approver reviews and submits. Different people.
One more piece most small businesses miss: journal entries. A user who can post a journal entry can move money between any two accounts without leaving a transaction trail in the operational areas. The classic small business fraud is to post a journal entry that debits an expense account and credits cash, recording a payment to a vendor that never existed. In QBO Advanced, the right control is to limit journal entry rights to the controller or external CPA only, and to require a workflow approval for any journal entry over a defined dollar threshold. If you have a bookkeeper who needs to make adjusting entries, the workflow routes those over $1,000 to the owner for sign-off before they post.
What if you only have two people? You can still get partial separation by splitting authorization and recording on each transaction type, and by having an external CPA do the monthly reconciliation as a third-party review. That hybrid (two internal roles plus an external review) is what we set up for most of our NYC clients in the under-$5M revenue range. It is not perfect, but it is materially better than letting one person do everything, and it gives you the documented control structure an auditor or a lender will want to see if you ever need a business loan or an audit.
One more pattern worth calling out: the “owner override”. Problem. In most small businesses, the owner has Company Admin rights and can do anything in the file. That is necessary for the owner to actually run the business, but it also means the owner can quietly bypass every control you built. The right answer is not to strip the owner’s access. The right answer is to make sure every owner-initiated action is visible. We do that with two practices: every quarter the controller pulls the audit log filtered to actions by the owner and reviews it, and any owner-initiated journal entry over a defined threshold (we usually set $2,500) triggers a workflow notification to the external CPA. The owner can still act without delay. The audit trail still shows the action. Nobody has unilateral, unmonitored authority.
Documentation is the piece most teams skip. Build the roles, then write them down. We keep a one-page document per client titled “Role Definitions and Segregation Map.” It lists each role, the permissions, the scope filters, the workflow approvals attached, and the explicit segregation pairs (AP Clerk separated from AP Approver, etc.). When a lender or an insurance carrier asks for evidence of controls, that one-pager answers most of the questions in under five minutes.
For very small teams (two or three people), full SOD across every transaction type is impossible without help. The fallback we recommend: pick the two riskiest transaction types in your business (usually bill payment and payroll), enforce segregation on those at all costs, and accept that lower-risk transactions (expense receipts under $50, time entries) can run with looser controls. The risk-weighted approach acknowledges reality: a 100% segregation policy in a three-person shop will get ignored within a month. A 60% policy that’s actually followed beats a 100% policy that isn’t.
Can QBO Advanced custom roles satisfy SOX or PCAOB audit requirements?
The short answer is no on their own, and a useful yes when combined with other controls. Sarbanes-Oxley (SOX) applies to public companies and a few specific private situations. Section 404 of SOX requires management to document and test internal controls over financial reporting and requires the external auditor to attest to those controls. The PCAOB sets the auditing standards (most AS 2201) the auditor uses to evaluate whether the controls are working.
SOX does not say “you must use QuickBooks roles.” It says you must have effective internal controls over financial reporting and you must be able to demonstrate them. QBO Advanced custom roles are a tool you can use to build some of those controls, but they are not a complete answer on their own. A SOX-compliant control environment typically includes role-based access (which custom roles can provide), segregation of duties (which custom roles can enforce), an audit trail of changes (which the QBO audit log provides), evidence of approvals (which workflows and custom fields can capture), and periodic management review of access (which you have to schedule and document yourself).
Where QBO Advanced helps directly: the custom role builder lets you implement and document role-based access. You can print a list of each role’s permissions, attach it to your control documentation, and show an auditor exactly who can do what in the system. The audit log captures every change a user makes, with the user’s name, the timestamp, the record affected, and the before/after values. The workflow engine can document approval steps. Custom fields can capture approver names and dates. Used together, these features generate a meaningful chunk of the evidence a SOX auditor wants to see.
Where QBO Advanced falls short on its own: it does not generate the policy documentation, the risk assessment, or the management testing that SOX requires around the technology controls. It does not enforce password complexity or multi-factor authentication at the level a SOX auditor would prefer (though it supports MFA at the account level). It does not provide native quarterly access reviews. It does not produce a SOC 1 report on its own behalf for the parts of the platform Intuit operates. You can use Intuit’s published SOC reports (available on request) as evidence of platform-level controls, but the application-level controls you implement on top of QBO are still your responsibility to document and test.
The PCAOB question is narrower. PCAOB standards apply to the audit of public companies. If you are the company, you are not directly governed by PCAOB rules. Your auditor is. What this means in practice is that if your auditor uses PCAOB standards and your auditor wants evidence of segregation of duties, you need to produce that evidence from your system. QBO Advanced custom roles are usually sufficient to produce that evidence, provided you have actually configured the roles correctly and you have logs showing the roles in effect during the period under audit.
For private companies that are not subject to SOX but want to be ready for a future event (an IPO, a sale to a public company, a debt covenant requiring audited financials), we typically recommend implementing what we call “SOX-lite.” That means using QBO Advanced custom roles to enforce segregation of duties, scheduling quarterly access reviews where the owner or CFO reviews who has which role and why, requiring multi-factor authentication on every QBO login (set in account settings, not the role builder), and exporting the audit log quarterly to keep a permanent off-platform record. None of that is required by SOX for a private company. All of it makes the company more sellable and reduces the cost and pain of any future audit.
There is one specific gap to call out for any company subject to a real SOX audit. QBO does not natively support role-based separation between production and testing environments. There is no “QBO test company”. You can promote changes from. Every chart-of-account change, every workflow change, every custom role edit happens in the live company file. SOX auditors looking at change management controls often ask how you test changes before they go live. With QBO, the answer is “we don’t have a sandbox,”. And you have to compensate with documented review and approval steps for every configuration change. For most small private companies, this is fine. For a public-company subsidiary running on QBO Advanced, this gap is the single biggest reason auditors push management toward NetSuite or Sage Intacct.
If you are not subject to SOX and never will be, none of this is your problem. The custom role builder and audit log are more than enough for everyday internal control needs and for a typical lender or insurance audit. If you are subject to SOX or are planning to be, custom roles are part of the answer but not the whole answer. We help clients build the full control matrix when this comes up. It is a project, not a checkbox.
One detail SOX-curious clients always ask about: change management. Under SOX, every change to a financial system needs to be requested, approved and deployed with a documented trail. QBO has no native change-management workflow for configuration changes. When someone edits a custom role, that change goes live immediately, with only the audit log capturing it. For a SOX-subject company, that gap has to be filled with policy. We typically write a Change Management Policy stating that every QBO configuration change (role edits, custom field additions, workflow changes, chart of account changes) must be requested in writing, approved by the controller, and logged in a change-management spreadsheet kept outside QBO. The controller does a quarterly reconciliation of the change log against the QBO audit log to confirm every change was approved.
For private companies positioning for a sale or capital raise, demonstrating “audit-ready”. Controls is one of the cheapest ways to increase deal certainty. Buyers walk away from messy controls more often than they walk away from messy financials. The financials they can have their accountants clean up post-close. The controls failure is a sign of a deeper management problem they can’t price. QBO Advanced custom roles, used well, are part of how you prove controls maturity.
One operational note: SOC 1 reports from QBO are not the same as a SOC 1 report from your finance function. Intuit publishes a SOC 1 covering the platform itself (uptime, data integrity, security at the infrastructure level). That report does not cover how you configured the platform. Your role design, your workflow approvals, your access reviews — those are your controls, not Intuit’s. Auditors looking at SOX compliance want evidence of both layers, and they will not accept Intuit’s SOC 1 as proof that your custom roles are working. The two are complementary, not interchangeable.
How do I handle role changes when an employee gets promoted or leaves?
This is the part of role management that most companies do badly. Roles get assigned correctly on day one, and then someone moves teams, gets promoted, takes a leave, or leaves the company, and nobody updates QBO. Six months later the audit log shows a former AP clerk who is now in sales still has bill creation rights, or a person on parental leave still appears as the approver of record on transactions that were actually approved by someone else.
The cleanest way to handle this is to make role changes part of every HR event, not something the finance team remembers to do separately. Three triggers should always force a QBO role review: a hire (the new person needs a role assigned), a role change inside the company (the existing person needs a different role), and a separation (the leaving person needs their access removed). In our experience, the first and third get handled most of the time. The middle one (a promotion or lateral move) is the one that gets missed.
For promotions, the right move is rarely to expand the current role. If your AP clerk gets promoted to AP supervisor and you simply add more permissions to the AP Clerk role, you are now changing the role for everyone who holds it. That breaks the audit trail and it changes the meaning of every historical entry tagged with that role. Instead, build a separate AP Supervisor role with the expanded permissions and reassign the promoted person to the new role. The old AP Clerk role keeps its narrow scope. The historical record stays clean.
For departures, the worst pattern is to leave the user active but “stop using”. The account. Active users with valid credentials are an open door. QBO Advanced lets you deactivate a user, which preserves the historical record (all the transactions they touched still show their name in the audit log) but prevents future logins. Deactivation should happen the same day as the separation, ideally before the person leaves the building or signs off their last Zoom. If you can’t deactivate immediately, force a password reset and revoke any device tokens the user might have on a phone. The standard sequence for a departure is: lock the QBO account, lock email, lock VPN, collect company devices, then sit down with the bookkeeper to review what the departing person was working on.
For a leave of absence, you have a few options. The first is to leave the role assigned and assume the person will come back. That is fine for a short leave (under 30 days) for a non-sensitive role. For longer leaves or for sensitive roles (anyone with bill payment or payroll rights), the right move is to temporarily reassign the role to someone else and deactivate the original user. When the person returns, reactivate them and reassign. The audit log will show the gap and the temporary coverage, which is exactly what you want.
One under-used feature in QBO Advanced: the access summary. When you go to a user in Manage users, there is an Access summary panel that shows everything the user can do, derived from their assigned role. We recommend running this for every active user once a quarter and comparing it to what their actual job is. The mismatches are usually the result of accumulated changes that nobody documented. A user who started as an AP clerk, got promoted to AP supervisor, and then moved to FP&A might still have AP creation rights nobody remembered to remove.
The quarterly access review is the single most useful habit a finance team can build. It takes about an hour for a 20-user file. The output is a one-page report listing every user, their current role, and a flag from the manager saying “still appropriate”. Or “needs change.” Sign and date the report, file it. That report is exactly what a lender, an insurance carrier, or an external auditor will ask for if they want evidence of access controls. Most clients we work with had never produced one before we set the process up, and most realized during the first review that they had at least one user with rights they should not have had.
Handling consultants and contractors is its own subcategory. The pattern that works: every external person gets a role that expires. Build a Contractor role with the minimum permissions they need, set a calendar reminder for the contract end date, and deactivate the user on that date whether or not the contract is renewed. If the contract is renewed, reactivate the user (or build a new login) and reset the expiration. Without a hard expiration, contractor logins linger for years after the work ended. We have walked into client files where five-year-old consultants still had active accounts.
One more lesson learned the hard way: never share a login. Two people sharing a QBO account makes the audit log meaningless. If two people need similar access, give them separate accounts with the same role. QBO Advanced supports up to 25 users on a single subscription, so cost is rarely the constraint that pushes people toward shared logins. The constraint is usually laziness or a one-time temporary access need that became permanent. Catch it fast and split the login the same day.
A specific example that comes up every year: the seasonal employee. Restaurants, retail and event companies bring on temporary staff for a few weeks or months. The right pattern is to build a Seasonal Worker role with the absolute minimum access needed (usually just time tracking entry against specific jobs), set a hard end date on each user, and run a monthly review of every active user against the current payroll list. Anyone in QBO who is not on payroll gets deactivated the same day. We have seen seasonal staff from three seasons ago still active in QBO files, sometimes with permissions to enter time that nobody was reviewing.
The single document that protects you here is a one-page “User Lifecycle Policy”. That covers hires, role changes, separations and contractor end-dates. The policy lives outside QBO (we keep it in the client’s HR folder) and gets reviewed annually. Every time someone joins, leaves, or changes roles, the policy gets pulled out and walked through. Without the policy, the role hygiene work depends on whoever happens to remember, and remembering breaks down within months of any staff turnover. With the policy and the quarterly access review, you catch the misses before they become problems.
One more failure mode worth flagging: the “I’ll do it Monday”. Departure. An employee gives notice on Friday afternoon, has the weekend off, and Monday morning is when someone finally remembers to remove their QBO access. The weekend window between notice and lockout is exactly when a departing employee with bad intent has the most opportunity. The rule we set with every client: QBO access is removed within four hours of the resignation conversation, regardless of when the actual departure date is. The departing employee can come back into the file in a read-only Tax Preparer role for the final week if they need to wrap something up, but the full access ends on the day of notice.
What’s the right role for an external bookkeeper or CPA firm in QBO Advanced?
This question comes up every time a client brings in an outside bookkeeper or hires us to do their books or their tax return. The default that small businesses pick is “make them an admin,”. And that default is almost always wrong. An external bookkeeper or CPA firm needs broad read access to do their work, but the same broad write and admin rights that the owner has are usually too much. The right answer depends on what the external person is actually doing.
For an external bookkeeper who is responsible for monthly closes and ongoing data entry, the standard role we set up is what we call “Standard Bookkeeper.” That role has Create and View on all Sales and Expense transactions, View and Create on Banking (including reconciliation), Create and Edit on Journal Entries, View on Payroll (so they can record payroll journal entries from an outside payroll service), and full View on all Reports. It explicitly does not have user management rights, role-builder access, or company file settings access. The external bookkeeper can do every accounting task they need to do without being able to change who else has access or modify the structure of the file.
For a CPA firm doing the year-end tax return only, the role is much narrower. They typically need View only across the file (so they can see transactions, run reports, and tie out balances), no Create or Edit rights anywhere, and the ability to export reports and journal entry data. We call this role “Tax Preparer.” It is a read-only window into the file. The CPA firm cannot accidentally post a journal entry to fix something they think looks wrong without first sending a memo to the bookkeeper. That dependency is a feature, not a bug. The internal bookkeeper stays in control of the file. The external CPA stays in their lane.
For a CPA firm that is also providing controller-level services or tax planning during the year, the role expands to “Tax and Advisory.” That role adds Create and Edit on Journal Entries (so the firm can record year-end tax adjustments), View on Banking, and Create on a small set of internal reports needed for tax planning. The firm still cannot modify users, modify roles, or change company settings. They can make accounting changes but they cannot reshape the file.
One specific permission we always keep off for external users is the ability to modify the chart of accounts. The chart of accounts is the spine of the file. If an external bookkeeper renames or merges an account in the middle of a year, every report from that point forward looks different from every report before it, and reconciliation gets painful. The right control: chart-of-account changes go through the owner or controller, who reviews each one before approving. The external bookkeeper can suggest changes, but they cannot make them directly.
We also recommend a specific pattern for our own engagements. When we are doing client accounting services, we use a named user account for each of our staff members rather than a shared firm login. Each staff member has the Standard Bookkeeper role. The audit log then shows exactly which person at our firm made which change, which matters when a client calls a year later asking why a specific journal entry hit a specific account. Shared logins are a debugging nightmare. Named accounts cost nothing extra under the 25-user limit.
QBO has a separate concept called the Accountant user. An Accountant user is a special user type that an outside CPA firm can be invited as, and they get access to the QuickBooks Online Accountant tools, including the reclassify-transactions tool, the write-off-invoices tool, and the prep-for-taxes view. Accountant users do not count against the 25-user cap, which is one reason firms use them. The trade-off is that an Accountant user has very broad access by default, more like an admin than a tightly scoped Bookkeeper role. We use the Accountant user type for firms we trust to behave like an admin would. For everyone else, including some firms we work alongside on shared clients, we recommend a custom Bookkeeper role with the narrower scope.
One thing we never do for an external bookkeeper or CPA firm is grant Company Admin rights. The company admin in QBO is the single user who can transfer the master admin role, cancel the subscription, change the billing email, or invite new admins. That role belongs to the owner of the business, and it stays with the owner. If the owner is unavailable, the CFO holds it. It never goes to an external firm, even one we trust completely. The owner needs to be able to remove the external firm at any time, and the only way to guarantee that is to keep the master admin in-house.
The summary for any external relationship: give the minimum access needed for the work being done, name every user individually, set a quarterly review reminder, and keep master admin internal. Those four rules cover almost every case we see.
One process detail that prevents most of the friction we see between bookkeepers and CPA firms: an explicit handoff document at every period end. Once a month (or quarter, depending on engagement scope), the bookkeeper produces a one-page handoff note summarizing what’s closed, what’s open, and what was changed in QBO during the period. The CPA reviews the note before pulling reports. The note prevents the most common confusion (CPA pulls a report, sees an unfamiliar account, opens a panic ticket, finds out the bookkeeper created the account for a legitimate reason last week). A two-minute note saves an hour of confusion.
One last thought: the firm relationship is built on trust, but trust without verification is fragile. Even with a firm we have worked with for years, we want a documented audit log review at year-end showing what changes the firm made and why. Trust survives review. It does not survive surprises. The custom role limits combined with the audit log create the conditions where the relationship can stay healthy for the long run, because both sides know exactly what the other can do.
Pricing the engagement around the role matters too. A firm that asks for full admin rights and then bills by the hour has every incentive to make changes without documenting them. A firm that accepts a tightly scoped Bookkeeper or Tax Preparer role and bills against a defined scope of work has its incentives aligned with the client. We have walked away from engagements where a prospective client insisted on giving us admin rights “for convenience,”. Because the convenience cuts in both directions and we would rather operate with the friction of asking permission than the comfort of doing whatever we want.
Related Services
Client AccountingFull-stack finance operations AP, AR and reporting handled with proper segregation of duties baked in.
QBO AdvancedImplementation and role design Setup, custom role build-out, quarterly access reviews, and audit log monitoring. View All ServicesBrowse the full Reed Corporation service catalog.