QuickBooks Online Advanced Custom Fields: Tracking Data That Standard QBO Can't

This is the question that decides whether your reports will work or whether you will be untangling a data mess in 18 months. The three concepts overlap enough to confuse new users, but they are built for different jobs and once you internalize the distinction the design choices get a lot easier.

Classes. Classes are QuickBooks' primary segmentation dimension. They are built into the data model at a deep level. Every transaction line can carry one class. Every report — P&L, balance sheet, cash flow — can be filtered or pivoted by class. There is a built-in "P&L by Class" report that ships with the product. Classes show up in the Performance Centre as a first-class dimension. They are designed to answer the question "how is each segment of my business performing."

Typical use cases for classes: departments (Sales, Marketing, Engineering, Operations), business lines (Consulting Services, Software Subscriptions, Product Sales), or programs (for nonprofits and grant-tracked organizations). A consulting firm might use classes for service lines: Strategy, Implementation, Managed Services. A nonprofit might use classes for funding sources: Restricted Grants, Unrestricted Donations, Program Fees. The rule of thumb: if you want every report to break it out, it is a class.

Limits to know about: QBO Plus and Advanced both support classes, but Plus caps you around 40 active classes and Advanced effectively removes the cap (in practice the file slows down past a few hundred). Classes are off by default; turn them on in Account and Settings → Advanced → Categories. You can require a class on every transaction (we usually do this for clients who track by class at all — the partial-class scenario is worse than no classes), or leave it optional. Classes can be nested into a hierarchy, which sounds great until you have a five-level deep tree and your reports are unreadable. Two levels is usually enough.

Locations. Locations are the second segmentation dimension. They are designed for physical or operational separation — offices, stores, warehouses, regions in a delivery sense. Like classes, they ride at the transaction level, they have their own built-in P&L report (P&L by Location), and they show up in the Performance Centre. Where classes are usually about business function, locations are usually about geography or physical presence.

The tricky part: classes and locations are conceptually distinct but technically very similar. You could use locations as a second class hierarchy if you wanted. We do not recommend it — the naming conventions in reports, the way customers and vendors get tagged, and the muscle memory of the bookkeeping team all assume that locations are about places. Using locations to track something abstract creates confusion at handoff.

Limits on locations: similar to classes, with the same Plus vs. Advanced cap differences. Locations have one feature classes do not: a customer can be assigned a default location on their profile, which auto-populates on every transaction with that customer. This makes locations a natural fit for tracking which office serves which customer. Classes do not have that auto-populate behavior — every class assignment is per-transaction.

Custom fields. Custom fields are the third dimension and they work fundamentally differently. They are not baked into the data model the way classes and locations are. They ride on top of transactions and profiles as labels, but they do not automatically appear in every report. Each custom field has to be explicitly added to a report's filter or column list. The Performance Centre treats them as secondary dimensions and requires the Reportable toggle to be on.

This is the key distinction. Classes and locations are pre-wired to feed every standard report. Custom fields are user-built tags that feed reports you specifically build to use them. Classes and locations are infrastructure. Custom fields are metadata.

How to decide which to use. The decision tree we use with clients has three questions.

Question 1: Should this dimension appear in the standard P&L by default? If yes, it is a class. The CFO opens the monthly P&L; they expect to see the breakout. This dimension is structural to how the business reports. Departments and service lines almost always end up as classes for this reason.

Question 2: Is this dimension about a physical or operational location? If yes, it is a location. Office, warehouse, region, store, branch. The geographic or physical mental model is what makes locations the right fit, and the customer-default-location behavior makes it more convenient than classes for this use case.

Question 3: Is this a tracking attribute that some reports need but not every report? If yes, it is a custom field. Sales Rep, Deal Source, Project Code, Customer Tier. These do not belong on the standard P&L; they belong on specific operational reports like a commissions calc or a marketing-attribution dashboard.

A common scenario where the choice matters. A consulting firm has three service lines (Strategy, Implementation, Managed Services), two office locations (NYC and Chicago), and four sales reps. Service lines get classes — every P&L will break them out. Offices get locations — customers in NYC are served by NYC, customers in Chicago by Chicago. Sales rep gets a custom field — the commissions report needs it but the monthly P&L does not. That setup will scale cleanly to 10 reps, 5 offices, and 30 service lines without breaking anything. Mis-assign any of the three and the reports start fighting each other.

What happens when you misuse them. We have inherited files where the bookkeeper used a custom field to track department because they did not know about classes. The reports the owner asked for — P&L by department, expense breakouts — technically worked, but had to be rebuilt from scratch as custom reports because the standard reports do not pivot on custom fields. When the owner asked the bank for a P&L by department, they got a standard P&L with no department breakout, and the bank rejected the application until we rebuilt the file with classes properly. Cost the client about 30 hours of reclassification work.

The other direction. A client used a class for Sales Rep because they wanted to see "P&L by Sales Rep." Sounds reasonable. Six months later they had 12 reps, 4 of whom had left the company, and the class hierarchy was a mess. Worse, classes are required-on-every-line in their setup, so every bookkeeper had to pick a rep for every line of every transaction, including bills that had nothing to do with sales reps. The bookkeeping team was wasting 45 minutes a day on this. We migrated to a custom Sales Rep field on sales transactions only, marked optional, with a "Direct / No Rep" default. Time wasted dropped to zero and the commissions report still works.

Can you use all three at once? Yes, and we recommend it for any business with real operational complexity. The combination of classes for business segments, locations for geography, and custom fields for tracking attributes covers almost every reporting question we get. The trick is keeping each one disciplined — do not let custom fields creep into territory that classes should own, do not let locations multiply when the answer is custom fields, and do not pile classes when the answer is closing or merging old ones.

One final point on overlap. Custom fields are the only one of the three that can attach to customer and vendor profiles directly. Classes and locations live on transactions. If you want to tag a customer with their tier or industry or onboarding date, that has to be a custom field. We see this surprise people who try to put Customer Tier on classes and discover that classes do not work that way.

For a deeper look at structuring the dimensions in tandem with your chart of accounts, our QuickBooks Online bookkeeping guide has a section on segmentation strategy. And for the bookkeeping-process angle on getting classes, locations, and custom fields populated consistently across the team, our bookkeeping service includes a quarterly data-quality audit on all three dimensions.

The technical ceiling in QBO Advanced is generous. You get 12 active fields on sales forms, 12 on purchase forms, 10 on customer profiles, 10 on vendor profiles, and 10 on employee profiles. That is a theoretical 54 active custom fields across the file. We have never met a business that should actually have that many. The practical ceiling is much lower, and the consequences of overshooting it are bigger than people expect.

The number we recommend. For most service businesses, the right count is between 4 and 7 active custom fields total — covering the five core ones we discussed in the main article plus one or two business-specific additions. A law firm might add a Matter Number field. A construction firm might add a Job Cost Code. A SaaS company might add a Contract Renewal Date and an MRR-Tier field. Past 7, we start asking what the new field is going to feed. If the answer is not a specific named report, we do not build it.

Why fewer is better. Every active custom field is a small tax on every transaction or profile it attaches to. Five fields on every invoice means the AR clerk has five extra decisions to make per invoice. Multiply that by 200 invoices a month and you have meaningful time being spent on metadata. If the metadata is feeding live reports, it is worth it. If it is not, you are paying data-entry cost for no return.

The other reason fewer is better: data quality degrades with field count. We have seen this pattern repeat across dozens of clients. With three fields, the bookkeeping team fills them in correctly 95% of the time. With five, the rate drops to maybe 85%. With seven, you are around 70%. At ten, you are below 50% and the reports built on those fields are no longer trustworthy. The brain has limited bandwidth for "extra things to fill in on every transaction," and adding more fields does not give you more bandwidth, it just spreads the existing attention thinner.

When to start adding more. The honest answer: when a specific stakeholder asks for a specific report that needs a field you do not have, and that stakeholder has the political weight to keep asking. Marketing wants a Deal Source field for attribution? Build it. The CEO wants a Customer Tier so quarterly business reviews can prioritize? Build it. The CFO wants a Project Code so we can do real project profitability? Build it. But if the request is "wouldn't it be useful to track X" from someone who will never actually use the data, push back. Useful in theory is not useful in practice.

The audit cycle we run. Twice a year, for every Advanced client, we pull the field list and ask three questions for each one. (1) Is this field showing up in any report that has been run in the last six months? (2) Is the field being filled in on more than 80% of applicable transactions or records? (3) If the field were deleted tomorrow, would any stakeholder notice within 30 days? If the answer to all three is no, the field comes off. We mark it inactive rather than deleting it, which preserves the historical data on existing records but stops new records from being tagged. After a year of inactive status with no complaints, we delete it.

The audit usually finds dead fields. A typical Advanced file that has been live for two years will have somewhere between 8 and 15 custom fields, of which 3 to 5 are doing real work. The rest are leftover from a manager who left the company, a one-time project that ended, or a report someone built once and never refreshed. Pruning dead fields is one of one of the most useful things we do during a quarterly check-in.

The opposite mistake: too few fields. We see this less often, but it happens. A client has zero custom fields, runs every report on classes alone, and the reports are too coarse. The fix here is the same diagnostic as the too-many side: what reports does the team actually need, and which dimensions have to be on each transaction for those reports to work? Build the fields the reports need, not the fields someone imagines might be useful someday.

Specific use cases that drive higher field counts. A few business types legitimately need more fields than the 5-to-7 baseline.

Construction and trades. Job Cost Code, Phase, Foreman, Permit Number, Change Order Number. Construction accounting demands more dimensionality because every project has internal phases that have to roll up correctly for WIP reporting and lien-waiver tracking. We sometimes get to 9 or 10 active fields on a construction client and they all earn their keep.

Professional services with billable hours. Project Code, Phase, Billable-or-Nonbillable, Time-and-Materials-vs-Fixed-Fee, Hourly-Rate-Tier. The billable-hours data model needs more attributes per transaction to drive utilization reports and engagement profitability. Most law firms, accounting firms, and consulting firms run 7 to 9 active fields on time entries.

Multi-entity or franchise structures. Entity Code, Franchise Number, Royalty-Eligible-Flag, Inter-Entity-Transfer-Flag. These cases need fields to track which legal entity each transaction belongs to and which cash-flow stream it feeds. The number can creep up quickly.

Donor or grant tracking for nonprofits. Donor Code, Grant ID, Restriction Type, Allocation Method, Reporting Period. Nonprofit accounting on QBO usually needs more fields than a for-profit business of similar size because the reporting expectations from boards and grantors are denser.

The decision rule. Build a field only if you can name (a) the specific report it will feed, (b) the stakeholder who will use that report, and (c) the frequency the report will be run. If you cannot answer all three on the day you build the field, do not build it. We have a one-line documentation template for new fields: "Field Name — feeds Report X for Stakeholder Y, run Frequency Z." If that line is hard to fill in, the field is probably not worth creating.

Fields versus tags versus notes. Sometimes the answer is not a custom field at all. If you want to flag one-off transactions for some special handling, the Note field on every transaction can hold a free-text comment that the bookkeeper or AR clerk can search. If you want to track something that does not apply to most transactions, do not build a custom field that is blank 95% of the time — use a note or a tag instead. QBO Plus and Advanced both have a tagging system that is lightweight and good for ad-hoc dimensions.

What too many fields actually looks like. We took over a file last year that had 23 active custom fields. The previous bookkeeper had built one for every question anyone had ever asked. Transactions had fields for Sales Rep, Account Manager, Project Manager, Engagement Lead, and Relationship Owner — five fields that overlapped in meaning. The bookkeeping team had no idea which to fill in and was filling them inconsistently or leaving most blank. Reports were a mess. We spent the first quarter consolidating those five into a single Sales Rep field, retiring the others, and migrating the historical data. The lesson: it is much easier to keep fields out than to take them out.

Why this matters for outsourced bookkeeping. When a firm like ours takes over a file, custom-field discipline is one of the first things we assess. A file with 5 disciplined fields is a pleasure to work with. A file with 18 chaotic fields is a research project before we can produce reliable reports. Our client accounting services engagement includes a field audit in the onboarding phase, and a quarterly review thereafter, specifically because this is where data quality drifts fastest.

One final number. The best Advanced files we have seen, year after year, have between 4 and 6 active custom fields. The ones in trouble have more than 10. Aim for the lower end and resist the temptation to keep adding.

The short answer is yes, but not with native QBO tools. The longer answer is that the migration approach you pick depends on volume, how clean the historical data is, and whether you have a closing date that locks part of the period. Pick wrong and you spend three days fighting the import. Pick right and the backfill is done in an afternoon.

What QBO does and does not give you natively. Native QBO has no bulk-edit tool for custom fields. The Reclassify Transactions tool, which lives in the Accountant Tools panel, handles account, class, and location changes for accountant users, but it does not touch custom fields. The Spreadsheet Sync feature (also Advanced-tier) lets you push data in and out of Excel for some objects, but custom-field support is partial and brittle — we have had Spreadsheet Sync silently drop custom-field columns on import. The Excel import wizard in the data-management section handles new records but not bulk updates to existing ones.

This is a real gap in the product. The only reliable path for bulk custom-field updates is a third-party tool.

The two tools we recommend. Transaction Pro by Rightworks (formerly Right Networks) is the older option, around since the QuickBooks Desktop days, and ported to QBO. It handles imports and updates for transactions, customers, vendors, and items, with custom-field support. Pricing is roughly $499/year for a single-user subscription, more for multi-user. We use it most often for one-off migration projects where the client does not need ongoing bulk-edit capability.

SaasAnt Transactions is the newer competitor. Similar feature set, slightly cleaner interface, and a monthly subscription that scales with usage. Around $20-50/month depending on the tier. We tend to recommend SaasAnt for clients who anticipate ongoing bulk-edit needs — quarterly clean-ups, periodic reclassification work, or regular data imports from another system.

Both tools require you to authorize them in QBO. Both have a 30-day trial. Both will write custom-field updates to existing transactions, which is the specific capability we are talking about. If you only need to do one bulk update once, the SaasAnt trial is enough.

The bulk-update workflow. Whichever tool you pick, the workflow is roughly the same. Here is how we run it for a typical Sales Rep backfill of 18 months of invoices.

Step 1: Back up the QBO file. We cover backup in detail in the backup and restore guide. A pre-import backup is non-negotiable. If the import goes wrong, you want to be able to roll back without manually undoing each touched record.

Step 2: Export the transaction list with transaction IDs. From the Sales menu → Invoices, filter to the date range you want to update, and export the visible list to Excel. Make sure transaction ID is one of the columns — if it is not visible in the default export, customize the view to include it before exporting. The transaction ID is the key the import tool will use to match the update back to the right record.

Step 3: Pull the lookup data. If you are backfilling Sales Rep, you need a source of truth that maps each invoice (or each customer) to a rep. That source is usually your CRM — Salesforce, HubSpot, Pipedrive — or a spreadsheet someone has been maintaining manually. Export the lookup data, get it into Excel, and prepare for a VLOOKUP or XLOOKUP match against the transaction list.

Step 4: Build the matched file. In Excel, match transactions to the right rep using customer name or invoice number. Spot-check for unmatched transactions — these are usually customers who do not exist in the CRM (small one-off invoices, internal transactions, refunds) and you have to decide whether to leave them blank or assign a default. We usually create a "Direct / No Rep" option in the dropdown specifically for this gap. The output of this step is a clean CSV with two columns at minimum: transaction ID and Sales Rep value.

Step 5: Test on a sandbox. If you have access to a sandbox or trial QBO file, run the import there first. If you do not, run on the first 10 records of the production file and confirm the result before running on the full batch. Most import tools have a "preview" mode that shows what will change without committing — use it.

Step 6: Run the import. Pay attention to error messages. The most common errors are transaction not found (you exported the ID wrong), value not in dropdown (you are trying to write a value the dropdown does not contain — add it first), or transaction in closed period (more on this below).

Step 7: Spot-check. Open 20 random transactions after the import. Confirm the value landed correctly. Pull a report filtered by the new field value and compare against your source data. If the numbers match, you are done.

Step 8: Document what you did. A two-line entry in the file's change log: "Backfilled Sales Rep custom field on invoices from 2025-01-01 to 2026-05-10. Source: HubSpot export, matched on customer name. Imported via SaasAnt on 2026-05-11." If you ever need to defend the data later, this is your trail.

The closing-date problem. If your QBO file has a closing date set (Account and Settings → Advanced → Accounting → Close the books), transactions before that date are protected. Most import tools will throw an error trying to update locked transactions. You have three options.

Option A: do not backfill before the closing date. This is what we usually recommend. The closing date is a control intended to keep historical data stable. Punching through it to add metadata feels harmless but creates an audit-trail problem — the modified timestamp on those transactions will all read the date of the import, which can confuse future auditors.

Option B: temporarily remove the closing date, run the import, and re-set it. This works but requires admin access to the closing-date password and a discipline about putting it back. Document the temporary removal in the change log.

Option C: enter the closing-date password each time the import tool prompts for it. Most tools support this. Slower than Option B but does not require temporarily removing the protection.

Our default is Option A unless the backfilled metadata is specifically required for tax compliance or external reporting that touches the closed period.

Volume thresholds. Under 50 records, do it manually. The setup time for a bulk import is 1-2 hours, and you can update 50 records by hand in about that time. Between 50 and 500 records, use a bulk import use a bulk import — the setup time starts to pay off. Above 500, definitely use a bulk import; manual touch becomes a multi-day project.

What can go wrong. The most common bulk-import failure modes we see. (1) The source data is dirty — customer names with trailing spaces, abbreviated names that match one but not another, deleted customers that no longer exist. Clean the source first. (2) The dropdown values are not all in place — the import is trying to write "Jordan Reyes" but the dropdown only has "Jordan R." Update the dropdown before running the import. (3) The wrong transaction ID column — QBO has internal IDs and document numbers; make sure you are using the internal ID, not the doc number. (4) The import partially completes and stops. Most tools tell you which records succeeded and which failed; resume from the failure point rather than re-running the whole batch (which would update the successful records twice).

The IRS angle. Backfilling metadata to existing transactions does not change the underlying tax data and is not a tax reporting issue in itself. But for IRS recordkeeping purposes, you do want a clean audit trail of what changed and when. The IRS recordkeeping standards at irs.gov/businesses/small-businesses-self-employed/recordkeeping emphasize keeping books that accurately reflect income and expenses. A bulk-update on custom fields does not violate that, but if you ever face an audit, the change log we mentioned above is what answers the inevitable question of "why did all these transactions get touched on the same day in May."

When we recommend not backfilling at all. If the field tracks something only going forward (a new marketing channel, a new product line, a new account-management tier), accept the gap. Set a cutover date, document it, and live with the fact that the report will only have data from that date forward. Backfilling 18 months of historical data so the report can show a baseline that will not change anyone's decisions is bad math. The team's time is better spent on something else.

Our heavier-touch service. For clients on our client accounting services engagement, custom-field migration is part of the work we do during onboarding and quarterly clean-ups. We handle the export, the lookup, the import, and the verification. For DIY clients, the tools above are the right path. Just back up first and test on a sandbox.

This question comes up most years in October when the bookkeeping team starts thinking about year-end. The honest answer is that custom fields do not directly feed Form 1099-NEC or 1099-MISC reporting in QBO. The 1099 module reads other data sources entirely. But custom fields are still genuinely useful for 1099 prep work, just not in the way most people expect.

What the QBO 1099 module actually uses. When you run 1099 prep in QBO — Vendors menu → Prepare 1099s — the system pulls four pieces of data for each vendor: (1) the vendor's tax ID from the vendor profile, (2) the vendor's legal name and address from the vendor profile, (3) the box mapping you set up linking your expense accounts to specific 1099-NEC or 1099-MISC boxes, and (4) the actual payment data, which QBO calculates from the bills and expenses paid to that vendor in the calendar year. The vendor must also have the "Track payments for 1099" checkbox checked on their profile.

What is not in that list: custom fields. The 1099 module does not read any custom field, regardless of what it is named or what data it contains. If you create a custom field called "1099 Status" and tag every vendor with their box (NEC, MISC, exempt), the 1099 prep wizard will completely ignore it.

This catches people off guard because the field feels like it should drive the process. It does not. The box mapping in the 1099 wizard is what drives the box assignment, and that mapping is account-based, not vendor-based.

So why use custom fields for 1099 at all. Two reasons. First, custom fields are great for the human side of 1099 prep — the part that happens before you run the wizard. Second, they help you catch missing data before it becomes a year-end emergency.

The 1099-related custom fields we recommend on vendor profiles:

1099 Status (dropdown): options for Yes-NEC, Yes-MISC, No, Exempt-Corporation, Exempt-Other, Pending-W9. This tells the bookkeeping team at a glance which vendors need 1099 attention without opening each profile or running the wizard. A bookkeeper doing weekly bill processing can look at the vendor list and immediately see "okay, this vendor is Pending-W9, I should not pay them more than $599 until we get the form."

W-9 Receipt Date (date): when you received the signed W-9. Blank means you do not have one, which means you should not be paying the vendor more than $600 a year without IRS backup withholding obligations. We run a report quarterly that filters to active vendors with blank W-9 Receipt Date and year-to-date payments over $400 (the warning zone before the $600 threshold). That report drives the W-9 collection effort, which is much easier in July than in January.

Contractor vs. Employee Classification (dropdown): Independent Contractor, Statutory Employee, Reimbursement-Only, Vendor-Goods, Vendor-Services. This helps with both 1099 prep and the underlying classification audit that the IRS sometimes triggers. Misclassified contractors are an expensive problem; flagging them in the vendor file makes the classification visible and reviewable.

Last 1099 Filed (date): the date you most recently filed a 1099 for this vendor. Helps the team confirm continuity year over year and catch vendors who should have been filed for but were missed.

1099 Notes (text): a free-text field for anything specific to that vendor — "LLC taxed as S-corp, exempt, confirmed via W-9 2024-06-15." Future bookkeepers will thank you.

None of these feed the 1099 wizard. All of them feed the human process of getting ready to run the wizard and confirming the wizard's output is correct.

The October W-9 audit. Once you have the custom fields in place, the audit workflow looks like this. Mid-October, pull a report: active vendors, year-to-date payments greater than $400, with the 1099 Status and W-9 Receipt Date custom field columns. Sort by 1099 Status. For Pending-W9 rows, send a W-9 request to the vendor (we use Gusto Spark or a manual email; either works). For blank rows, decide the status — usually one of Yes-NEC, Yes-MISC, or Exempt-Corporation — and update the field. For Exempt-Corporation rows where the vendor is over $600, confirm the entity type is actually a corporation (check the W-9, do not just trust the vendor's name). For Yes-NEC and Yes-MISC rows, confirm the W-9 Receipt Date is filled in. If not, that is your action list.

By mid-November, every vendor on track to exceed $600 should have a W-9 in hand or be definitively flagged as exempt with documentation. By December, the vendor profile data should be clean enough that running the 1099 wizard in January is a 30-minute job rather than a three-day scramble.

Box mapping does the real work. The 1099 wizard's assignment of payments to boxes is driven by which expense accounts you map to which boxes. NEC Box 1 (nonemployee compensation) typically gets your Contract Labor, Professional Services, and similar accounts. MISC Box 1 (rents) gets your Rent account. MISC Box 6 (medical and health care payments) gets specific medical accounts if applicable. The mapping happens once during the wizard's setup pass and lives in the file going forward. Custom fields play no role in this.

One thing the box mapping does not handle: vendors whose payments span multiple boxes. If you pay a vendor for both contract labor (NEC Box 1) and rent (MISC Box 1), the wizard will only know to split them if your expense accounts split them. The fix is account discipline at the bill-entry stage, not a custom field. Train the bookkeepers to code bills to the right expense accounts and the 1099s come out right.

IRS source. The full instructions for Form 1099-NEC are at irs.gov/forms-pubs/about-form-1099-nec and for 1099-MISC at irs.gov/forms-pubs/about-form-1099-misc. The instructions cover the box-level reporting requirements, the corporate exemption (most C corps and S corps are exempt from 1099 reporting, with some specific exceptions for medical and legal services), the $600 threshold (which has not increased in decades and is currently still $600 for most boxes), and the e-file thresholds (companies filing more than 10 information returns total must e-file).

The K-2 / K-3 wrinkle. If you are a partnership or S-corp with international activity, your 1099 prep also has to consider Schedules K-2 and K-3 filing requirements. Custom fields do not feed those either, but you can use a custom field on the partner or shareholder records to flag international-activity status, which then drives a separate workflow. We do not recommend this for most small businesses — the K-2/K-3 question is more about the entity's tax return than the QBO file.

State 1099 filing requirements. Some states require their own 1099 filings on top of federal. New York does not have a separate state 1099 filing for most cases, but California does, and several other states have variations. The custom field worth adding here is "State 1099 Required (dropdown or text)" on the vendor profile, listing the states where the vendor needs a state-level filing. This is more important for clients with vendor bases spread across many states; for NYC-centric clients, the federal filing usually covers it.

What we do at year-end for clients on our service. Our bookkeeping engagement includes 1099 prep as part of the year-end close. We use a standard set of custom fields on every client's vendor list (the five listed above plus one or two client-specific ones), run the W-9 audit in October, confirm the box mapping is current in November, and run the wizard in mid-January. The total time investment per client is usually 4-6 hours of focused work spread across three months, which is much less painful than the alternative of a 10-hour week in January cleaning up vendor data before filing.

If your current QBO file has dozens of vendors but no custom-field discipline on the 1099 side, you can still get there before next January — the fields are quick to set up, and even partial data is better than no data when you are trying to triage the year-end work. Just do not expect the field to drive the wizard. The field is for the humans; the wizard works off accounts and payments.

Yes, with the right user setup — and the access controls matter more than people realize, both for getting work done efficiently and for protecting sensitive data that some custom fields end up holding.

The two user types that touch custom fields. QBO has two distinct user models: regular users (added via Manage Users) and accountant users (added via the Accountant Tools panel). They look similar from the outside but behave differently around custom fields and other Advanced features.

Accountant users get added through the Invite Accountant flow. They count against a separate user limit (two accountant users on Plus, two on Advanced, with the option to add more on Advanced as an add-on). Once accepted, an accountant user gets access to the Accountant Tools panel — Reclassify Transactions, Write Off Invoices, Voided/Deleted Transactions report, and several other tools that regular users do not see. Accountant users see and edit custom fields by default, on every form and every profile. There is no granular permission for accountant users; they have full read-write across the file.

Regular users get added through Manage Users with a role selected from the role list. Roles include Primary Admin (one per file), Company Admin (basically the same as Primary Admin), Standard with specific permission sets, Reports Only, Time Tracking Only, and several others. On Advanced, you can build Custom Roles that fine-tune the permission set further.

For most CPA/bookkeeper relationships, the right setup is to invite the firm as an accountant user. This gives them full access without using up a billed user seat (accountant users are free at the Advanced tier), and it puts the firm in the right user category for things like the Accountant Tools panel and the cleaner audit-log treatment of accountant actions.

Custom field visibility by role. Custom fields appear on forms based on the form's permission. If a Standard user has access to invoices, they see custom fields on invoices. If their role does not include sales transactions, they do not see invoices at all and therefore do not see the custom fields on them. The custom field permission is bundled with the form permission — you cannot show the form but hide the custom field, unless you use a Custom Role.

Custom Roles in Advanced change this. You can build a role that grants invoice access but hides specific custom fields. For example, a Custom Role for an outside sales contractor might give them access to invoices but hide the Customer Tier custom field (because tier data is sensitive). Setting this up: Settings → Manage Users → Custom Roles → create a new role → set form permissions → expand the form's permission and toggle individual custom field visibility. The granularity is decent but not perfect — you can hide a field entirely but cannot show it as read-only without making the user role read-only on the whole form.

Sensitive custom fields. Some custom fields end up holding genuinely sensitive data and access controls matter. Customer Tier is the obvious one — the data that says "this customer is At-Risk" should not be visible to the customer-facing sales team because if it leaks (and it always leaks), the customer relationship damage is real. Deal Source is sometimes sensitive for similar reasons; you do not want a customer to see that they were tagged "Cold Outbound" on the invoice.

The fix is twofold. First, do not put sensitive custom fields on customer-facing print-out fields — turn off Print on Form for anything sensitive. Second, restrict edit access via Custom Roles so only the team that should see the data can see it. For Customer Tier, we typically grant edit access to the leadership team and the account-management leads, view-only to the rest of the leadership team, and hidden to everyone else.

Common role setups for outsourced bookkeeping. A few patterns we use repeatedly with clients.

Owner / Primary Admin: full access, sees everything, can edit everything. There is exactly one Primary Admin per file and changing them requires the existing Primary Admin to initiate the transfer.

Outside CPA firm: accountant user, free seat, full read-write. This is us, in most engagements. The accountant user designation makes our work visible in the right way to the audit log and gives us the Accountant Tools panel.

Outside bookkeeper / CAS firm: also accountant user, same setup. If multiple firms are involved (a CAS firm doing daily work and a CPA firm doing year-end), both get accountant user seats. Advanced supports more than two; check the current seat limit in Manage Users.

Internal bookkeeper: Custom Role with full transaction access, full vendor and customer access, but no banking-side permissions to initiate payments. The bookkeeper can see and edit every custom field but cannot move money. We use this setup to maintain segregation of duties between the person doing the bookkeeping and the person approving cash movement.

Sales rep with limited access: Custom Role with sales-form access only, hidden Customer Tier, view-only on Deal Source. The rep can create invoices and quotes and see their own deals, but cannot see the strategic context that lives in the sensitive fields.

Department head viewing reports: Reports Only role. Sees custom-field-driven reports without being able to edit underlying transactions. This is the right role for a CMO who wants to see Deal Source attribution without being able to retroactively re-tag the data.

Custom field permissions in the audit log. When a user edits a custom field on a transaction, the change shows up in the QBO audit log with the user's name, the timestamp, the record changed, and the before/after values. This is the same treatment as any other field change. For accountant users, the audit log entry is tagged with the accountant's firm and individual login, which is useful for tracing who did what.

One gap: the audit log records the change but does not record the reason. If a custom field gets changed three months after the original entry, the audit log will show the change but not why. Best practice is to document the reason in the transaction's memo field at the time of the change. We tell our bookkeepers to add a memo note any time they update a custom field after the fact — something like "Updated Sales Rep field per CRM correction, see ticket #4521." This pairs with the audit log to give a complete trail.

Setting up role-restricted access on a specific field. The walkthrough: Settings → Manage Users → click Custom Roles tab → New Role (or edit an existing one) → in the form permissions, expand the relevant form (Customer, Invoice, etc.) → you will see a list of all custom fields attached to that form → toggle individual visibility. Save. Apply the role to the relevant users. Test by logging in as a user with that role (you can use an incognito browser window) and confirming the field is hidden.

One thing to watch: custom fields you create after the role is set up do not automatically inherit the role's settings. New fields default to visible to everyone. You have to revisit the role and explicitly hide the new field. We have a quarterly checklist that includes "review custom fields against role permissions" specifically because this gets missed when new fields get added in between.

For multi-entity setups. If you run multiple QBO files (a holding company plus subsidiaries, for example), each file has its own custom fields and its own user permissions. The same person can be invited to multiple files with different roles in each. Custom fields do not sync between files — you have to create them in each file separately, which can be tedious for clients with five or six entities on the same chart of accounts. We have a setup script that pushes a standard custom-field template to each new entity file during onboarding so the configurations stay consistent.

What we look for in a file we are taking over. When we take over a QBO Advanced file, custom-field access controls are one of the first things we review. The questions: who has full access, who has restricted access, are sensitive fields actually hidden from the people who should not see them, and is the audit log clean enough to defend if needed. About a third of the files we inherit have at least one significant access-control gap — usually a former employee whose access was never revoked, a too-permissive Standard role that should have been a Custom Role, or a sensitive field that is print-on-form when it should not be. Fixing these is part of our onboarding work.

If you want a review of your current setup, our client accounting services intake includes a permissions audit on the QBO file. We will tell you what is open, what should be closed, and the priority order to fix it. The free version of the same thinking: pull your user list this week, confirm every name on it still works at the company, and confirm every Standard user is in a role that actually matches what they do day-to-day. That alone catches most of the gaps.

For the broader walkthrough of Custom Roles and how they interact with workflows, the Accountant Tools panel, and the audit log, see our custom roles guide.