SOP for Accounting Department: Best Practices for Small & Mid-Sized Teams in 2026

It’s common to find finance teams sitting on a binder of “accounting SOPs” hundreds of pages deep. Ask how many people actually use them and the honest answer is usually: maybe a dozen.

That’s the dirty secret of accounting documentation. Most departments either have nothing, or they have a SharePoint folder stuffed with three-year-old Word docs that no one trusts. Both are dangerous. One leaves you exposed when your AP clerk goes on maternity leave. The other hands auditors something to poke holes in.

I’m Yuval, founder and CEO of Glitter AI. I spend a lot of time with finance leaders at small and mid-sized companies who are trying to build a real SOP program, not a pile of documents. A program. This post is about the best practices for doing that. Not what each individual SOP should contain (I have other posts for that), but how to design, roll out, and keep the whole system alive so it actually works in 2026.

If you’re an Accounting Manager, Controller, or Finance Director setting up an SOP program from scratch, or trying to fix one that’s gone stale, this is for you.

Capture accounting SOPs as you do the work

Teach your co-workers or customers how to get stuff done – in seconds.

Try Glitter free

Replay video

0:00 / 0:00

Start with the 80/20: which processes need an SOP first

Here’s the mistake I see most often. Someone reads an article about SOPs, gets fired up, and tries to document everything at once. Three weeks in, the project stalls. The team is exhausted. The SOPs that did get written are half-finished.

Don’t do that. Apply the 80/20 rule.

In a typical accounting department, roughly 20% of your processes account for 80% of your risk and your operational pain. Document those first. From what I’ve seen working with finance teams, that 20% almost always includes:

• Month-end close - the single highest-leverage SOP in any accounting department
• Accounts payable - invoice intake, three-way match, payment runs
• Accounts receivable - invoicing cadence, collections escalation, cash application
• Bank and credit card reconciliations - anything that touches cash
• Payroll processing - even if outsourced, your internal handoff needs an SOP
• Sales tax filings - multi-state SMBs, this is your audit nightmare
• Year-end close and 1099 prep - annual but high-stakes

A useful filter I give people: ask “if this person quit on Friday, would I be in trouble on Monday?” If yes, document it now. If the honest answer is “we’d figure it out in a day,” it can wait.

I recently spoke with the head of a Sage 100 implementation practice. Their team documented an entire AP workflow in 52 SOPs for a client, and the way they did it matters. They didn’t sit in a conference room for a month planning a giant project. They recorded each task as it came up in the actual work. Invoice arrives, record. Vendor onboarding, record. Payment exception, record. By the end of the quarter, they had 52 working SOPs that reflected reality, not theory.

That’s the model. Capture during work, not in a workshop.

Design principle #1: one task, one SOP

The most common design mistake I see is the monster SOP. You know the one. A 47-page Word document called “Accounts Payable Procedures” that covers vendor onboarding, invoice intake, three-way matching, payment runs, exceptions, and 1099 reconciliation in a single file.

Nobody reads it. Nobody updates it. And when an auditor asks “show me your invoice approval procedure,” your team has to scroll through 30 pages to find the relevant section.

Break it apart. The rule of thumb I use: one SOP = one task that one person performs in one sitting. If a process spans multiple people or multiple sessions, it’s actually multiple SOPs that should reference each other.

For accounting specifically, that means instead of one giant “AP Procedures” doc, you’d have:

• “How to enter a vendor invoice in QuickBooks Online”
• “How to set up a new vendor with W-9 collection”
• “How to process the weekly AP payment run”
• “How to handle an invoice with a PO mismatch”
• “How to reconcile the AP aging at month-end”

Each one is short, focused, and easy to update. When QuickBooks changes its invoice entry screen, you update one SOP. Not page 12 of a 47-page document.

Design principle #2: decision-tree SOPs vs linear SOPs

Not every accounting task is linear. Some are pure step-by-step (enter invoice, code GL account, save). Others have branches (is this invoice over $5K? Is the vendor new? Does it have a PO?).

A good SOP program uses both formats and knows when to use which.

Linear SOPs work for routine, repeatable tasks with no decision points:

• Running a standard report
• Daily bank deposit entry
• Recurring journal entry posting

Decision-tree SOPs are essential for tasks with branching logic:

• Invoice approval routing (under $5K vs over $5K vs over $25K)
• Customer credit decisions
• Variance investigation procedures

A common pitfall is jamming everything into a linear format. You end up with SOPs full of “if X, then go to step 7. If Y, then skip to step 12.” That’s a decision tree pretending to be a checklist, and it’s a mess to follow. If you have more than two if/then statements, switch formats.

Stop writing accounting SOPs from scratch

Glitter records your screen as you work, then auto-generates a clean SOP with screenshots and steps.

Start free

Replay video

0:00 / 0:00

Design principle #3: write for the new hire, not the expert

Every accounting SOP I’ve ever read suffers from one of two problems. It’s written by an expert for an expert, or it’s so dumbed down that experienced staff find it insulting.

The right calibration is: write for someone who knows accounting fundamentals but has never used your specific stack or seen your specific charts of accounts. That’s your new hire on day 30.

In practice that means:

• Don’t explain what “AR aging” is. Do explain which AR aging report your team uses and where it lives in NetSuite.
• Don’t define “three-way match.” Do specify your match tolerances and where exceptions get routed.
• Show the actual screen. Don’t say “navigate to the vendor record.” Show a screenshot with the menu path circled.

Honestly, this is where most documentation falls apart. The person writing it knows the system so well they can’t see what’s invisible to a beginner. The fix is to either have someone newer write the first draft, or use a tool that captures the actual clicks (more on that below).

Version control: the SOX/audit angle

If you’re a public company, a public-company subsidiary, or a private company headed for an exit, version control on your SOPs isn’t optional. It’s part of your control environment.

Even if you’re a private SMB with no SOX obligations, auditors will ask about your procedures. A documented version history is what separates “we have SOPs” from “we have a controlled SOP program.”

The minimum bar:

1. Every SOP has a version number and last-updated date visible at the top of the document
2. Changes are logged with who changed what and why
3. Old versions are archived, not deleted. Auditors sometimes ask to see the procedure as it existed during a specific period
4. Approval is documented. At minimum, the SOP owner and one reviewer signed off on the current version

You can do all of this in SharePoint, Notion, Confluence, or a dedicated SOP tool. The platform matters less than the discipline. What matters is that when an auditor says “show me the AP approval procedure that was in place as of December 31, 2025,” you can produce it in under five minutes.

RACI: who actually owns each SOP

This is the part most accounting departments skip, and it’s why their SOP libraries rot.

Every SOP needs an owner. Not “the accounting team.” A specific person whose name is on the document. The owner is responsible for:

• Keeping the SOP current
• Reviewing it on a defined cadence
• Approving any changes
• Training new staff on it

A simple RACI matrix for an accounting SOP looks like this:

• Responsible (does the work): the staff accountant who performs the task
• Accountable (owns the SOP): the senior accountant or AP/AR lead
• Consulted (input on changes): the controller, IT for system changes
• Informed (notified of changes): the broader accounting team

The accountable person matters most. Without a named owner, every SOP is everyone’s job, which means it’s no one’s job. I’ve watched SOP libraries die for exactly this reason.

For SMBs, a controller might be Accountable for everything. That’s fine. The point is that someone’s name is on each document.

Training cadence: how to actually roll out SOPs

Writing the SOP is maybe 30% of the work. Getting your team to use it is the other 70%.

Here’s the cadence I recommend for a new SOP rollout:

1. Pilot with one person for 2 weeks - have them perform the task using only the SOP. Capture every “wait, that’s wrong” or “this step is missing.”
2. Revise based on the pilot - usually 20-30% of the SOP gets rewritten. That’s normal and good.
3. Walk-through with the team - 30 minutes max. The owner walks through the SOP, the team asks questions.
4. Shadow period (1-2 weeks) - anyone new to the task uses the SOP under supervision.
5. Quarterly refresher - for high-stakes SOPs (close, payroll, tax), revisit quarterly even if nothing has changed. People forget.
6. Annual review - every SOP gets reviewed annually whether or not it’s changed. Owner signs off that it’s still accurate.

That last one is what keeps the library alive. Without an annual review, SOPs decay quietly until someone needs one and finds out it’s three versions out of date.

How to test an SOP before rollout

A test I love: hand the draft SOP to someone who has never done the task and ask them to perform it with zero help from you. Watch them do it. Don’t intervene unless they’re about to actually break something.

Every place they hesitate, ask a question, or do the wrong thing is a gap in the SOP. Fix those gaps. Then test it again with someone else.

This sounds expensive. It isn’t. A 30-minute test session can save you from a 6-month-long stretch of new hires getting confused and asking the same questions over and over. For an accounting team that hires 2-3 people a year, a tested SOP pays for itself almost immediately.

For a deeper walkthrough of what should go inside each individual procedure, my earlier post on the accounting SOP guide covers that ground.

Capture accounting SOPs as you do the work

Teach your co-workers or customers how to get stuff done – in seconds.

Try Glitter free

Replay video

0:00 / 0:00

Common pitfalls I see at SMBs

After watching a lot of SMB accounting departments try to build SOP programs, the same mistakes keep showing up.

Pitfall 1: over-documentation

Writing SOPs for things that don’t need to be documented. If a task happens twice a year, performed by the same senior person who’s been there for a decade, you probably don’t need a 12-page SOP. A one-paragraph note in their year-end checklist is fine.

The cost of over-documentation is real. Every SOP you write is an SOP you have to maintain. Maintain too many and you maintain none of them well.

Pitfall 2: never updating

The flip side. SOPs get written, filed, and never touched again. Two years later, QuickBooks has changed three times, your chart of accounts has been restructured, and the SOP describes a process that no longer exists. Worse, new hires follow it anyway and create a mess.

The fix is the annual review I mentioned above. Schedule it. Put it on the calendar. Don’t skip it.

Pitfall 3: SOP-as-cover-your-ass document

This one is subtle and toxic. Some teams write SOPs primarily to assign blame when something goes wrong. “Well, the SOP says you should have done X, so this is your fault.”

When SOPs become weapons, the team stops trusting them. People start documenting in the most defensive, vague way possible. The whole program becomes performative.

SOPs exist to make people effective, not to create a paper trail for firing them. If your team senses the latter, your program is dead before it starts.

Pitfall 4: writing in Word, storing in email

Don’t. Use a real platform - SharePoint, Notion, Confluence, Google Drive with a proper folder structure, or a dedicated tool. The format matters less than having a single source of truth that everyone knows how to find. For SMBs comparing platforms, I’ve written a broader piece on SOP management best practices that’s worth a read.

Pitfall 5: tool-specific SOPs that ignore the underlying logic

If your SOP says “click the blue button in the top-right of QuickBooks Online,” what happens when Intuit redesigns the UI? You’re rewriting every screenshot.

Better approach: explain the what and the why alongside the how. “Record the vendor invoice (Vendors → Enter Bills) - this creates the AP liability and starts the payment clock.” Now if QuickBooks changes the menu, you update the path but the rest of the SOP still works. For QuickBooks-specific guidance, see my QuickBooks training walkthrough.

Tooling: QuickBooks, Sage, NetSuite, Xero

A note on platform-specific SOPs. The accounting tools your team uses shape your documentation in ways people don’t always think about.

• QuickBooks Online - the UI changes frequently. Your screenshots will go stale. Plan for refreshes.
• Sage 100 / Sage Intacct - more stable UI, but the customization layer (especially in Sage 100) means every install is different. Document YOUR configuration, not generic Sage workflows.
• NetSuite - heavily customized, role-based. SOPs need to be role-specific because what an AP clerk sees is completely different from what a controller sees.
• Xero - cleaner UI than QBO, less change. But the integrations (Hubdoc, Dext, etc.) are where most documentation gaps hide.

The takeaway: don’t copy a generic “QuickBooks AP procedure” off the internet. Your AP procedure depends on your chart of accounts, your approval thresholds, your integrations, and your team. Document YOUR process.

A quick word on capture method

The Sage 100 story I mentioned earlier - 52 SOPs captured as the work happened - is the model I keep coming back to. The reason it works is that it inverts the usual flow.

Most SOP projects go like this: stop the work → schedule documentation time → write SOPs → resume work. That fails because documentation time always loses to month-end.

The capture-as-you-work model is: do the work → capture it as you go → clean up the capture later. Documentation becomes a byproduct of work, not a separate project.

This is exactly why I built Glitter. It records your screen and clicks while you do the task, then auto-generates a clean SOP with screenshots, step descriptions, and a shareable link. You spend zero “documentation time.” The SOP exists when you finish the task. Whether you use Glitter or a screen recorder and Loom or a plain phone camera, the principle is the same: capture during the work, edit after. The difference is that Glitter produces a written SOP alongside the video; Loom just gives you a video your team has to watch end-to-end.

Putting it all together: a 90-day rollout plan

If you’re starting from zero, here’s a realistic 90-day plan:

Days 1-15: Inventory and prioritize

• List every recurring accounting process
• Apply the 80/20 filter - circle the top 10
• Assign an owner to each

Days 16-45: Capture the top 10

• Each owner records themselves performing the task
• Use the “one task, one SOP” rule. Don’t try to document a whole function in one doc
• First drafts only. Don’t perfect anything yet

Days 46-60: Pilot and revise

• Hand each draft to someone who didn’t write it
• Watch them try to perform the task
• Revise based on the gaps you observe

Days 61-75: Roll out and train

• 30-minute team walk-through of the new SOPs
• Set the storage location (one place, everyone knows where)
• Establish the annual review calendar

Days 76-90: Build the cadence

• Document the next 10-20 processes using the same model
• Schedule quarterly check-ins for the top 10
• Celebrate the win - your team just built a real SOP program

In my experience, SMB accounting teams that follow something like this end up with 30-50 working SOPs by the end of year one, covering the vast majority of operational risk, without burning out the team or producing a graveyard of unused documents.

That’s the goal. Not hundreds of SOPs that nobody uses. 30-50 that everyone trusts.