Accounts receivable is the money customers owe you for invoices you've already sent but haven't collected yet. It's a core term in the accounting glossary: a current asset on the balance sheet, not revenue on the P&L. The revenue already hit the books when the invoice was sent. AR just tracks the unpaid balance until the customer pays.
AR shows up in the current assets section of the balance sheet, usually right under Cash and Cash Equivalents. It's "current" because the receivables are expected to convert to cash within twelve months (for most service businesses, within thirty to sixty days). A small services firm might carry $40,000 to $120,000 in AR depending on terms, billing cadence, and how aggressively they collect.
The AR balance equals the sum of every open invoice across every customer. If a customer has paid half a $10,000 invoice, the open balance is $5,000. That's the number that lives in AR.
On a typical small business balance sheet, the order is Cash → AR → Other Receivables → Inventory → Prepaid Expenses → Total Current Assets. Lenders look at the AR-to-revenue ratio (DSO, days sales outstanding) to gauge how fast customers actually pay. A 30-day-terms business with 65 DSO is collecting too slowly, and that shows up in AR before it shows up in cash flow.
This is the AR mirror of the AP-vs-expense confusion. Revenue hits the P&L when the invoice is created (under accrual). AR is the unpaid portion of that revenue, sitting on the balance sheet. When the customer pays, AR decreases and Cash increases. The P&L doesn't move. If you posted the payment as additional revenue, you'd double-count.
The fix when this happens: reverse the duplicate revenue, match the payment to the original invoice, and re-run the P&L. The income statement primer walks through how revenue posts at invoice time, not payment time.
Three timestamps matter: invoice date, due date, and payment date. AR cares about the gap between invoice and payment.
Under accrual accounting, revenue is recognized when earned, typically when goods are delivered or services are performed. The invoice formalizes that recognition. A May 31 invoice for May consulting work is May revenue. The customer has Net 30 terms and pays June 25. Revenue stays in May; the cash arrives in June. The P&L for May reflects the work that was done in May, not the cash that arrived later.
This is the entire point of accrual accounting: the matching principle puts revenue and cost in the period the work happened, not the period the bank account moved.
The same May 31 invoice that posted $4,800 to revenue also posted $4,800 to AR. From May 31 until June 25, AR carries that $4,800. On June 25, when payment arrives, AR drops by $4,800 and Cash rises by $4,800. The journal entry is debit Cash, credit AR. The P&L doesn't move; revenue was already recognized.
If the invoice is partially paid (say $2,400 on June 25 and $2,400 on July 10), AR drops in two steps. Each payment matches against the same invoice until the open balance hits zero.
Cash moves on payment date. For a Net 30 invoice, that's typically thirty days after the invoice date, though customer payment habits push the average past terms in most small businesses. The lag between invoice date and cash date is exactly what AR is tracking.
A common dashboard mistake: pulling the AR balance and labeling it "open revenue." It's not. AR is gross unpaid invoices; it includes invoices that may already be in dispute, customer credits not yet applied, and (sometimes) sales tax. Revenue is the P&L number, run for a specific period. AR is a balance sheet snapshot of what's outstanding right now.
Invoice creation (May 31):
Payment receipt (June 25):
Net effect: revenue stayed in May, cash arrived in June, AR was a temporary holding account in between. This is the spine of accrual bookkeeping. See the GL deep dive for how these post through the broader system.
QBO's AR workflow has three core actions: invoice the customer, receive the payment, and reconcile customer balances.
The path is "+ New" → "Invoice." Fill in customer, invoice date, due date, terms (Net 15, Net 30, Due on Receipt), product/service line items, and amount. Save. QBO debits AR and credits the revenue account tied to each line item. The invoice now shows in the customer's history and in AR aging.
A common error: setting the invoice date to the date you sent it, not the date the work was done. For a clean accrual P&L, use the date the work was performed. If you provide a service in March but send the invoice April 5, the invoice date should still be March 31 (or whatever date in March the work was completed). Otherwise revenue lands in the wrong period.
When payment arrives, the path is "+ New" → "Receive Payment." Pick the customer, select the open invoices being paid, choose the deposit-to account (a bank account or Undeposited Funds), and save. QBO debits Cash (or UF) and credits AR for the same amount.
If the payment is going to be deposited as part of a batch with other customer payments, post to Undeposited Funds and then create a Bank Deposit when the batch hits the bank. This is exactly the design intent of UF: to let multiple customer payments collapse into one bank-statement deposit during reconciliation.
Sales Receipt skips AR. Use it only when payment is received at the moment of sale: point-of-sale, e-commerce checkout, or any transaction where there's no terms gap between sale and cash. The journal entry is debit Cash, credit Revenue. AR isn't involved because nothing was ever owed.
The decision rule: if you're invoicing the customer with payment terms, it's an Invoice and AR sees it. If they paid you on the spot, it's a Sales Receipt and AR doesn't. Mixing the two creates AR ghosts (sales receipts entered as invoices, never paid because they were already paid).
Use Sales Receipt for: cash sales, e-commerce orders that auto-pay, retainer payments where there's no separate invoice, point-of-sale transactions. Don't use Sales Receipt for: services billed monthly, projects with deposit-and-balance billing, or anything else where the customer needs an invoice document.
The payment-matching step is where books drift if you skip it. When a customer sends $4,800 against three open invoices, QBO needs to know which invoices to mark paid. If the bookkeeper just creates an Expense or a Bank Deposit for $4,800 without applying it to specific invoices, AR doesn't decrease, and now the invoice is double-paid in the system's mind.
The fix: always use Receive Payment with the specific invoices selected. If the customer overpays, QBO will create a credit on the customer's account for future application.
AR aging shows which invoices are how overdue, and bad-debt accounting handles the ones that won't get paid.
The default QBO aging report buckets are Current, 1-30, 31-60, 61-90, and 90+ days past due. A healthy AR for Net 30 terms has 80%+ of dollars in Current and 1-30. Drift right of that means collections is slipping. Drift further than 60 means the invoice is at risk.
The AR aging is the collections team's day-one tool. It also tells the bookkeeper which customers to flag for follow-up and which invoices may be heading toward write-off.
The allowance method anticipates that some receivables won't be collected and records that estimate as a contra-asset on the balance sheet. The entry is debit Bad Debt Expense, credit Allowance for Doubtful Accounts. AR stays at gross face value; the allowance reduces the net realizable value reported on the balance sheet.
A typical estimate is a percentage of AR (1-3% for healthy books, higher for industries with collection risk) or an aging-weighted formula (0% on Current, 25% on 60-90, 50% on 90+, 100% on 120+). The exact rate depends on historical collection experience.
Direct write-off recognizes bad debt only when a specific receivable is determined uncollectible. The entry is debit Bad Debt Expense, credit AR. Simple, but it doesn't match the period: the original revenue was recognized months earlier, and the expense lands in a later period.
Allowance method is GAAP for most businesses with material AR. Direct write-off is acceptable for very small books or when bad debt is rare. Most QBO files start on direct write-off and migrate to allowance only when AR grows.
Switch when AR exceeds roughly 20% of annual revenue, when bad debt has historically run more than 0.5% of revenue, or when lenders or investors require GAAP statements. Below those thresholds, direct write-off is administratively simpler and rarely materially wrong.
For tax, bad debt under §166 still requires worthlessness determination: the debt must be actually uncollectible, not just slow-paying. Documentation matters: collection attempts, customer communications, evidence the customer has gone out of business or filed bankruptcy. A direct write-off without documentation can be reversed by the IRS on audit.
For accrual-basis taxpayers, the deduction is in the year the debt becomes worthless. For cash-basis, there's no bad debt deduction; you never recognized the income, so you can't deduct the loss.
Five mistakes cover almost every messy AR balance.
When a payment is entered as a revenue line instead of as Receive Payment against the open invoice, revenue double-counts and AR never closes. The fix is to reverse the duplicate revenue and apply the payment correctly. Bank-feed match prompts catch most of these in real time. If you stay on top of the bank feed, this rarely happens.
A payment received without invoice matching shows up as a deposit but the invoice stays open. AR aging then shows a 90-day-old invoice that's actually paid, sitting next to a 30-day-old unmatched cash receipt. The cleanup is the same: find the cash receipt, match it to the invoice. See accounts payable (AP) for the same pattern in reverse on the vendor side.
A customer prepayment is a liability, not negative AR. If a customer pays $10,000 in advance for work that hasn't been invoiced yet, the entry is debit Cash, credit Customer Deposits (a current liability). When the work is performed and invoiced, the deposit is applied: debit Customer Deposits, credit AR (which the new invoice already debited).
If you post the prepayment as a Receive Payment against an invoice that doesn't exist, QBO creates a credit on the customer record. That works as a workaround but obscures the liability. A customer who's prepaid $10,000 should appear as a $10,000 liability on the balance sheet, not as a customer-credit footnote.
Carry deposits in a separate Customer Deposits liability account. Reconcile it monthly: which customers have unapplied deposits, and against what future work? This is one of the cleanest signals to a tax preparer or auditor that the books are well-kept.
The AR subledger total (sum of all open customer balances in the customer center) must tie to the AR control account on the GL each month. A mismatch means a journal entry was posted directly to AR without a customer record, almost always a mistake to investigate.
Growthy is bookkeeping software, not a CPA firm. This content is educational, not professional advice. Full disclaimer.
Related: Accounting & Bookkeeping Glossary, Accounts Payable (AP): What It Is & How It Works, General Ledger (GL): The Backbone of Your Accounting System, Income Statement (P&L): How to Read & Use Your Profit and Loss
Free during alpha. Read-only access. You review every sync.
CPA firm partner who got tired of watching bookkeepers click categorize 500 times a day. Built Growthy to fix it.
View all articles →Growthy is dedicated to helping businesses of all sizes make informed decisions. We adhere to strict editorial guidelines to ensure that our content meets and maintains our high standards.
Undeposited Funds is the QBO holding account where customer payments sit between receipt and bank deposit. It exists so a single bank statement deposit can match multiple customer payments. Here's how to use it correctly and clear stuck balances.
Uncategorized Expense is QuickBooks Online's catchall for transactions imported but never assigned to a real category. A clean book has $0 in this account. Here's how to recategorize what's there and prevent new ones from landing.
The trial balance lists every GL account with its debit or credit balance, proving total debits equal total credits. Here's how to read it, and the troubleshooting framework for when it doesn't balance.