How to Restrict a QuickBooks User to Their Own Customers

You hired a second sales rep. Now both reps log into QuickBooks, open the customer list, and see every account in the company. They can read each other's invoices, payment history, aging, and totals. You want each rep limited to the accounts assigned to them, so you go looking for the permission setting.

There is no permission setting. Here is the short answer, then the mechanics.

The Short Answer

No tier of QuickBooks scopes user permissions to a subset of customers. Permissions are scoped by feature area (Customers and sales, Vendors and purchases, Reports, Banking), not by individual record. A user who can see one customer can see all customers.

This is not a setting you have failed to find. It is how the permission model is built. The check QuickBooks runs is "may this user open the sales area," not "which customer rows may this user read." There is no owner column on the customer record for the permission system to read against.

So if you need per-rep customer scoping, the rule has to be enforced somewhere other than QuickBooks. The rest of this covers what each tier actually allows, how to confirm that in your own file in about a minute, what the common workarounds break, and what a rep-facing layer really involves.

What Each QuickBooks Tier Allows

Two things worth naming, because they are what people mistake for the answer.

The Rep field is not a permission. QuickBooks Desktop has a Rep field on customers and sales forms. It exists so you can run a Sales by Rep report. It is a reporting dimension. A rep viewing that report can clear the filter and see everyone. QuickBooks Online has no native Rep field at all; Advanced lets you create a custom field for it, and a custom field is still just data sitting on the record.

Classes and locations are not permissions either. They partition your reporting, not your access. A user can change the class filter on any report they are allowed to run.

Confirm This In Your Own File In About A Minute

Do not take my word for it, and do not take a vendor's word for it either.

In QuickBooks Online: Settings, then Manage users, then add or edit a user and step through every permission screen. In Advanced: Settings, then Manage users, then Roles, then create a custom role and open every category.

What you are looking for is a control that accepts a list of customers, or a rule shaped like "only records where this field equals this user." If every control you find is a level (Full access, View only, None) applied to a whole category, then it is category level and the answer above holds.

This check matters because Intuit ships feature variations by plan and by region, and third-party pages sometimes describe Advanced custom roles in language that sounds record-level when the underlying control is category-level. Sixty seconds in your own account settles it. If you find a real customer picker in there, that is the tier to buy, and you can stop reading.

The Four Workarounds, And What Each One Costs

One company file per rep. This works, in the sense that the walls are real. It also destroys consolidated A/R, breaks company-wide reporting, multiplies your subscription cost, and makes month-end close significantly worse. Shared vendors, shared chart of accounts, and any customer who buys from two reps all become manual reconciliation. Almost nobody who tries this is still doing it a year later.

Classes or locations. Covered above. Reporting partition, not access control.

A reports-only user plus scheduled reports. You email each rep a filtered report on a schedule. Cheapest option, and it genuinely helps some teams. The limits are obvious: stale between sends, no search, no drill-in, read-only.

Third-party add-ons. Several exist. Evaluate all of them with one question: where is the filter enforced? Most connect with a company-wide token, pull everything, and apply the rep filter inside their own interface. That is a legitimate architecture, and it is exactly the architecture described below with a vendor holding your token. Judge on price, support, and workflow fit, not on a belief that the tool is doing something QuickBooks permissions cannot.

What Actually Works: A Rep Layer On Top Of QuickBooks

QuickBooks stays the accounting system of record, and nothing about your books changes. A separate, deliberately small application owns the two things QuickBooks does not model: who owns which customer, and the rule that a rep only ever sees their own. Reps log into that layer. Bookkeeping, accountants, and owners keep working in QuickBooks with full access.

The Data Model

The ownership table is the whole idea, and it should be many-to-many from the first day:

• customer_qbo_id, the QuickBooks Id, not the display name
• rep_user_id
• role, because primary and secondary rep on one account is common
• effective_from and effective_to, because accounts get reassigned and you will need to answer questions about last quarter

Everything else is a cached copy of QuickBooks data plus a filter.

What the QuickBooks API Gives You, And What It Does Not

This is the part that decides the design, so it is worth being precise.

A QuickBooks connection is authorized against a company, not a user. The OAuth 2.0 token your app receives is bound to a realm, which is the company file. There is no way to mint a narrower token that returns only one rep's customers. Every read your application performs comes back unfiltered, for the entire company.

That single fact means the scope filter is your application's responsibility on every query, every list, every export, every dropdown, and every total. There is no safety net behind it. A missing WHERE clause in one handler leaks the whole book.

Reading is straightforward. The Accounting API exposes a query endpoint with a SQL-like syntax against entities such as Customer and Invoice, paginated with a start position and a max results value. Pulling a full customer list is not the hard part.

Staying in sync is the part people underestimate. QuickBooks webhooks are notification-only: an event tells you the entity type, the record Id, the operation, and a timestamp. It does not carry the record. You fetch it yourself. You also have to assume you will miss events, so plan a reconciliation path using the change data capture endpoint to pull everything modified since a given timestamp after any downtime.

Do not call Intuit on page load. The API is throttled per company. Cache customers and invoices locally, serve reps from your own store, and reconcile on webhook plus a schedule. That is the difference between a tool that feels instant and one that times out at 9am when everyone logs in.

Test custom field round-trips before designing around them. If your plan is to store the rep name in a QuickBooks custom field and read it back through the API, verify that exact round trip on your own plan first. Custom field coverage in the API has historically been narrower than the web interface suggests.

The Failure Modes That Actually Bite

These are the ones that show up after launch, not during the demo:

1. Unassigned customers become invisible. Every filter needs a defined behavior for records with no owner row, or new accounts silently disappear from everyone's view. Pick a default owner or an explicit unassigned queue.
2. Reassignment erases history. When an account moves from one rep to another, does the new rep see three years of old invoices, and does the old rep lose them instantly? Effective-dated ownership answers this. A single owner_id column on the customer does not.
3. House accounts are many-to-many. The account two reps share will exist. Model it on day one or retrofit it painfully later.
4. Aggregates leak what lists hide. The customer list filters correctly, then a dashboard tile shows total company revenue. Every count, sum, and chart has to run through the same filter as the list.
5. Autocomplete leaks. The customer picker on a new invoice form is a query too. It is the single most commonly missed one.
6. Merging customers in QuickBooks destroys an Id. Your ownership row now points at a record that no longer exists. Detect it and handle it rather than letting the sync fail quietly.

Points 2 and 6 are both really the same requirement: you need a record of what changed and when. That is one of the reasons audit trails belong in internal tools from the start rather than being added after the first dispute.

The order system I built for a wireless distributor enforces permissions this way. Roles gate which actions a user can take, and every query that returns records applies the scope filter on the server before anything reaches the browser. The pattern is identical whether the scoped records are orders or customers.

How Big Is This Build

Scope splits cleanly at one line: read-only or write-back.

A read-only rep view (login, assigned customer list, customer detail with invoices and balance, basic search, an ownership admin screen) is a small, well-bounded internal tool. The QuickBooks sync is the bulk of the work, not the interface.

A layer where reps also create estimates or invoices that push back into QuickBooks is a different project. You are now writing to the accounting system, which means validation, duplicate protection, and a real answer for what happens when a push fails halfway. Run the build versus buy comparison honestly before committing, because a third-party add-on may be the right call at this size.

The cost estimator will get you a usable range before you talk to anyone.

The useful next step is smaller than a build, though. Spend the sixty seconds in Manage users and confirm the limitation in your own file. If it holds, write down how many reps, how many customers, and whether reps need to create anything or only read. Those three answers determine everything else.