Accounts Receivable SOP Examples: Invoicing and Collections Procedures

An operator once gave us his whole business in six words: get work, do work, get paid. The 5 accounts receivable SOP examples below cover the third part, the one most small businesses run on chasing instead of procedure: invoice creation, payment recording by method, the deposit chase, contract completion, and the collections ladder. Each is built from processes we have documented inside real companies: the trigger, the steps, and the decision points that make it work.

Key takeaway: An accounts receivable SOP is a written procedure for one part of getting paid, captured from the person who runs it. In receivables the judgment calls are the document, and the first one to settle is when a payment counts as real: a card confirms itself, cash is a claim until it is banked.

What Is an Accounts Receivable SOP?

An accounts receivable SOP is a written procedure for one piece of the getting-paid side of the business: creating an invoice, recording a payment, verifying a deposit, completing a contract, or collecting what is overdue. It names the trigger, the steps in order, and the judgment calls the person will face, so the money side runs the same way no matter who runs it that week.

AR earns its own SOPs because it is where trust in your data lives or dies. When we document a process for a client we capture 3 things: the purpose, the decision points, and the step-by-step from the person actually doing the work.

In receivables, the decision points are the whole game. When is a payment real? Who may approve an invoice that does not match the quote? On what day does a reminder become a phone call?

The cost of skipping them is not hypothetical. One owner we worked with took over his own payables for a few weeks after a key employee left and found 500 to 800 dollars leaking every week from a process nobody followed, about 10,000 dollars a month. Receivables leak the same way, just quieter: invoices that age in silence, cash that never reaches the bank, contracts missing a signature nobody noticed.

Our accounting SOP examples cover the payables side of that leak. Everything below stays on the money coming in.

If you have never written a procedure at all, our SOP examples from other departments show the same anatomy applied outside the money side.

Accounts Receivable SOP Example 1: Invoice Creation and Delivery

The purpose of this SOP is speed and zero surprise. The invoice goes out fast, matches what was promised, and lands on a customer who already knows the number.

We learned the delivery half the expensive way. A client agreed on scope, we delivered the work, and the invoice still landed as a shock: "I did not realize it would be this much." The number had never been anchored in writing, so the invoice was doing a job no invoice should do, breaking news.

An invoice should never be the first time the customer sees the number.

The skeleton is small. Trigger: the job record is marked done. Owner: one named role, not "the office". Done when: the invoice is sent and a follow-up date is logged.

1. Confirm the job is closed. Invoice only from a record marked done. Half-closed jobs are the most common reason an invoice never goes out, and the jobs-done rule closing this page is how you stop them.
2. Build from the record. Line items come from the system where the work was logged, never from what anyone remembers agreeing to.
3. Check the written promise. Compare the total to the quote. A mismatch goes to a named approver before the invoice goes out, not after the customer calls.
4. Send same day, with a summary. One short paragraph of what was delivered, in plain words.
5. Log the follow-up date. Collections starts the day you send, not the day someone remembers.

The decision point worth writing down is step 3. Decide once who may approve a total that differs from the quote, and by how much, and you stop learning about pricing disputes from angry phone calls.

Example 2: Payment Recording by Method

At one field service company we documented, around 70 employees strong, card payments hit the CRM the same second the customer paid. Cash and checks were claims. Anyone could mark a job "paid cash" with nothing in the bank yet, and the office lived in a constant reconciliation chase because of it.

The fix is not banning cash. It is an SOP that records the method at the moment of payment, because the method decides what has to happen next.

Read the middle column again, because it is the whole example: each method has a different definition of paid. Record the method with every payment, because the method decides which procedure runs next.

A card closes itself. A check enters a verification loop. Cash enters the chase, which is the next example.

Example 3: The Deposit Chase for Cash and Checks

That same company had a payments app that could verify a check by photo, and it still chased deposits every week. The chase is the tell. When you hear "chasing" in your own office, chasing receipts, chasing deposits, chasing confirmations, you are listening to a missing procedure.

A payment is real when the bank agrees, not when somebody says it happened.

This SOP turns the chase into a check that runs on a schedule. Four steps carry it:

1. List unbanked payments daily. Every job marked paid by cash or check with no matching deposit yet. Most systems can produce this list; almost nobody looks at it.
2. Set a deposit deadline. Next banking day is a reasonable default. What matters is that a deadline exists and everyone knows it.
3. Verify checks on receipt. If your payments app can photo-verify a check before the tech leaves the driveway, make that a step, not an option.
4. Escalate misses by name. A deposit past deadline goes to one named person, the same way every time. No group chat archaeology.

One honest observation: this list usually lives in a spreadsheet only one person can read, which swaps one single point of failure for another. That holds while volume is small. When spreadsheets stop scaling covers the point where the workbook becomes the riskiest system in the building.

Example 4: Contract and Signature Completion

A 16-store franchise we worked with takes deposits remotely, so money arrives before the paperwork is complete. To find which contracts were missing a countersignature, managers paged through their e-signature envelopes one by one, opening each to check. Completion was a discovery, not a status.

Track contract completion as a queue you work, not a surprise you find.

The SOP is short. Trigger: a deposit is taken or a sale is recorded. Done when: every signature is on file and the record says complete. In between: log the contract the day money changes hands, check the countersign queue on a fixed schedule, and chase anything incomplete with a named owner and a deadline.

The judgment call to pre-decide is the stop rule. What pauses when a signature is missing: the delivery, the start of work, the next payment? Write the answer into the SOP so a manager is not inventing policy at the counter with a customer standing there.

Example 5: The Collections Ladder

Collections procedures fail for a human reason: nobody wants to make the awkward call, so the call quietly does not happen and the invoice ages in silence. A ladder fixes that by pre-deciding every rung, which turns following up into administration, not confrontation.

Collections fail on courage, which is exactly why they should never require any.

A working ladder for a small business has 4 rungs, and yours can rename the days:

• Day 0: send and log. The invoice goes out and the follow-up date is logged. Example 1 already handled this.
• Day 7: written reminder. A friendly email, written once, sent verbatim.
• Day 14: the relationship call. A phone call from whoever holds the relationship, with a script written as spoken words, the way a person would actually say them.
• Day 30: the escalation decision. A named role chooses between a payment plan, a stop on new work, or a write-off, against thresholds set in advance.

Your day numbers can differ. What cannot differ is who owns each rung and what triggers the next one, because the moment a reminder becomes a call is exactly where an undocumented process breaks.

---

How Do You Write an AR SOP?

Every example above came out of the same method, one you can run internally. Five steps take a receivables procedure from habit to a document a new hire can follow.

1. Pick one procedure. Not "fix AR". One of the 5 above, whichever is bleeding most this month.
2. Record the person doing it. We never ask someone to write down how they do their job; we record them doing it, because the truth lives in execution, not memory. Whoever chases deposits knows failure modes the owner has never seen.
3. Write the decision points. When is a payment real, who approves a mismatched invoice, what stops when a signature is missing. These judgment calls are the procedure; the steps mostly exist to reach them.
4. Write glance-test steps. Verb-first lines a reader can act on without stopping to read a paragraph. The full skeleton, with a copy and paste template, is in our guide on how to write an SOP.
5. Test on a fresh person. Hand the draft to someone who has never done the task and watch them run it. Every hesitation is a gap in the document, not in the person.

Notice what this refuses to do: it never starts from a template of what AR should look like. It starts from what your people already do, then tightens it, which is why the result gets followed.

The Jobs-Done Rule That Protects Everyone's Pay

Every procedure on this page leans on one upstream fact: the job record flipped to done. At the field service company in Examples 2 and 3, jobs that never got flipped meant invoices that never went out and technicians who did not get paid for work they had finished. The CRM even had a report for unsettled jobs. Nobody used it, so the bookkeeper reconstructed each week from group chat threads before anyone saw a paycheck.

So the last rule is the first one to implement. A job is closed by a named person following a named step, never by somebody remembering. Put the flip inside a step that already has to happen, taking the payment or leaving the site. The closeout procedure itself sits with our field operations SOP examples, because it belongs to the crew doing the work, not to the office.

This is the work we do at The Systems Effect: interviewing the people who chase the deposits and close the jobs, then turning what they know into procedures the team can run. You do not need us to start, though.

Pick the example that made you wince and write that one this week. If nothing did, start with the deposit chase. It is the shortest SOP on this page, and the first week it runs you will know how much of your revenue has been living on a promise.

Frequently Asked Questions

What should an invoicing SOP include?

An invoicing SOP should name the trigger (a job record marked done), one owning role, and a definition of done (invoice sent, follow-up date logged). The steps: build line items from the system of record, check the total against the quote, route any mismatch to a named approver, and send the same day with a short summary of the work. The decision point worth spelling out is who may approve a total that differs from the quote.

How do you document a collections process?

Start by recording the person who currently does the chasing, because the real process lives in their habits, not in anyone's memory. Then write the ladder: day numbers for the reminder, the call, and the escalation, with one named owner per rung and the phone script written as spoken words. The judgment calls, when a reminder becomes a call and a call becomes a decision, are the most important lines in it.

Why do cash payments need a different procedure than card payments?

A card payment verifies itself: the processor confirms it the second it runs, so your system and the bank agree automatically. Cash is only a claim until the deposit hits the bank, and in an undocumented process anyone can mark a job paid in cash with nothing banked yet. That is why cash needs its own loop: a daily list of unbanked payments, a deposit deadline, and a named follow-up.

How do you track unsigned contracts?

As a queue, not a search. Log every contract the day money changes hands, check the countersignature queue on a fixed schedule, and chase incomplete contracts with a named owner and a deadline. The failure mode to design against is the manual hunt, paging through e-signature envelopes one by one, which turns completion into a discovery instead of a status.