Month-End Close Checklist for E-commerce Client Books

Generic checklists verify work a human built. E-commerce client books are built by software — so the close is five verifications of automated output, in a specific order, in about 30 minutes.

---

The close was marked done on the 8th. Your staff bookkeeper worked the firm's standard checklist — transactions categorized, bank accounts reconciled, every box ticked. Then you opened the file for partner review and found a Shopify payout from the 3rd sitting in the bank feed, unmatched, with a clearing account carrying a balance nobody could explain.

The month was closed around a hole. And the worst part is that the checklist didn't fail — it passed. It just wasn't checking for the thing that was wrong.

If your firm runs a month end close checklist ecommerce clients keep slipping through, this is why. The checklist wasn't built for how these books get made. This post is the replacement: a per-client runsheet a staff bookkeeper can execute in about 30 minutes, with times and a pass condition for every step.

Why "Books Are Books" Fails at Partner Review

The lie underneath the bounced close is a reasonable-sounding one: a close checklist is generic — books are books. Categorize, reconcile, review, lock. Why would a Shopify client's close differ from a law firm's?

Because the books were built differently. A law firm's ledger is constructed by a human, so the close verifies human work: is everything entered, coded, reconciled? An e-commerce client on a sync tool has machine-built books — the software posts the sales entries, separates the fees, records the refunds. The construction already happened. What the close has to verify is automated output, and automated output fails in ways generic checklists never probe.

A sync error nobody noticed on the 14th means eleven orders never reached QuickBooks — and "reconcile the bank account" won't catch it, because the bank feed doesn't know those orders exist. A deposit matched to a lump "Shopify income" line passes bank rec while double-counting revenue. Sales tax posted to an income account looks fine on every generic checklist ever written, right up until the tax filing.

So the e-commerce close adds five client-specific verifications, in a deliberate order — each one gates the next. None of them is construction work. All of them are checks on what the automation produced. (If a client fails several of these every single month, the problem is upstream of the close — run the 15-minute file diagnostic and scope a cleanup instead of closing a broken file twelve times a year.)

The Month-End Close Checklist for E-commerce Clients

Total time: about 30 minutes per client, assuming the client was onboarded on a standard template so every file uses the same chart and mappings. Everything below is written for LedgerPort, but the logic ports to any sync tool that exposes a per-record log.

Pre-close: triage the error log — 5 minutes

The day before the close, open the client's Audit Log and filter Status to Error. Every row is a record that never reached QuickBooks, with the reason attached — "Product not mapped," "Customer not found." Fix what's fixable (add the mapping, create the customer), and for anything that can't be resolved today, write it down as a hold with a reason.

After each fix, re-push just the affected records — tick the rows, click Sync Selected. No full re-sync, no waiting for the next scheduled run.

Clean looks like: the Error filter shows only rows that already have a documented hold. Nothing in the list is a surprise.

Verification 1: the error-log sweep — 3 minutes

On close day, sweep the full month. Filter the Audit Log to the period, then check each status: Error should be empty (or only your documented holds), Pending should be empty — a record still queued on close day means something is stuck — and every On Hold row should have a known trigger reason, like an order awaiting payment.

This step goes first because one unsynced order invalidates every number downstream. There is no point tracing payouts over books with holes in them.

Clean looks like: zero unresolved Error rows for the month, zero Pending, every On Hold explained.

Verification 2: the payout-to-deposit trace — 6 minutes

Pick one payout from the month — the largest is the best stress test — and follow it end to end: gross sales posted to income, fees to the fee expense account, refunds to contra-revenue, and a net amount that matches the bank deposit to the penny. One payout that ties completely proves the mapping, the fee separation, and the deposit matching in a single trace.

This is a sample, not a census — the automation posted every payout the same way, so one full trace plus step 3 covers the rest. The mechanics of why payouts and deposits diverge, and how the payout journal keeps them tied, are in the payout reconciliation guide.

Clean looks like: the traced payout's net equals the bank deposit exactly, with every component in its own account. A penny off means a fee or adjustment landed somewhere wrong — find it before moving on.

Verification 3: the clearing zero-check — 3 minutes

Open the clearing account register as of month-end. The balance should be zero — or exactly the sum of in-transit payouts: orders paid in the last days of the month that Shopify hasn't disbursed yet.

The key word is exactly. You should be able to name the specific pending payouts that compose the balance. A residue you can't attribute is the early warning for the unmatched-payout problem — the one from the 3rd that bounced your last close.

Clean looks like: clearing equals zero or equals a list of named pending payouts, and nothing else.

Verification 4: the sales tax tie-out — 4 minutes

Pull the month's tax collected from Shopify's tax report and compare it to the movement in the sales-tax liability account in QuickBooks. The two numbers should match. Confirm refund tax reversed against the liability account too, not against income.

This step catches the quietest failure in e-commerce books: tax collected posting as revenue. It inflates income, understates the liability, and no bank reconciliation will ever flag it.

Clean looks like: Shopify tax collected equals the liability account movement for the period, net of refund reversals.

Verification 5: the refund-period review — 4 minutes

Run the month's refunds and check three things: each posted as contra-revenue rather than deleted income, the original processing fee stayed expensed (processors keep it), and cross-period refunds — this month's refund of last month's sale — landed in this month, not edited back into the closed one. Compare the total against Shopify's returns figure for the period.

Refunds go last because they're the period-boundary step: this is where you confirm nothing reached backward into a month you're about to lock. The full treatment — contra-revenue, fees, tax reversal, restocking — is in the refunds and returns guide.

Clean looks like: refund total matches Shopify, all refunds in-period, no prior-period entries modified.

Post-close: lock and report — 5 minutes

Lock the period in QuickBooks: Settings → Advanced → Close the books, set the closing date, add the password. An unlocked close isn't a close — it's a suggestion.

Then send the client one paragraph. A template your staff can fill in three minutes:

June close is complete for [Store]. All 1,214 orders synced to QuickBooks with zero unresolved errors. Every payout traced to its bank deposit; the clearing account returned to zero at month-end. Sales tax collected ties to the liability account at $4,860. Refunds for the period: $2,310, recorded as returns. One item to flag: [item]. Books are locked as of July 3.

Running It Across 15 Clients

One runsheet is 30 minutes. Fifteen clients is 7.5 staff hours — the question is how to schedule and supervise them.

Batch by day, not by client whim. A close can't start until the month's last payout settles, which usually means the 2nd or 3rd. Schedule five clients a day across days 3–5: two and a half staff hours per day, every close done by the 5th.

Split the roles. Staff run the full runsheet on every client. The partner doesn't re-run anything — they spot-check one verification per client, rotating: the payout trace on the biggest files, the tax tie-out or clearing check on the rest. Because every step has a written pass condition, "reviewed" means checking a stated result, not re-deriving it.

Keep clients isolated. The runsheet only works at volume if a fix in one client can't leak into another. In LedgerPort, each client is its own Business — one store paired with one QuickBooks company, fully isolated, with its own audit log, mappings, and sync settings under a single firm login. Staff switch clients from the business picker and the runsheet reads identically in every one.

Send the Checklist to the Client

Here's the move most firms skip: attach the completed runsheet to the monthly summary.

To a client, "monthly bookkeeping" is an invoice line they can't see inside. Five named verifications with results — errors swept, payout traced to the penny, clearing at zero, tax tied out, refunds reviewed — is visible diligence. It converts the retainer from a fee they tolerate into a report they'd miss, and it's precisely the kind of legible, systematized work that supports pricing on value instead of hours.

There's a selfish benefit too. A client who reads that paragraph every month never asks what they pay you for — and tells other store owners about it.

The payout from the 3rd doesn't get caught by working harder. It gets caught by a checklist that knows machine-built books fail differently — and checks for exactly that, in order, in 30 minutes.

Book a CPA onboarding call → and we'll set up your first client with you — connections, mappings, and a first close run against this exact runsheet, so your next partner review finds nothing.