Português

Audit Prep That Doesn't Blow Up Q4

It's December 18. Year-end close is still open. Your auditor's PBC list has 47 outstanding items, six of which were due November 30. Your AP lead just gave notice, your senior accountant is out with the flu, and the senior associate from the audit team has emailed three different people on your team in the last 48 hours, asking for the same lease schedule in slightly different formats.

This is what bad audit prep feels like. It's not a smarts problem. It's a calendar problem. And it's almost entirely avoidable.

The controllers who survive Q4 without losing staff are the ones who already finished half the audit work by November. The ones who treat audit as a Q1 sprint lose their best people to recruiters in February, when the LinkedIn messages start landing and the team is too tired to ignore them.

This is the playbook. Real numbers, real diagnoses, and a Q3-to-Q1 calendar you can run.

Why Q4 Blows Up (Every Year, Same Way)

Audit ramp lands the same week as year-end close. AP cutoff, accruals, the revenue waterfall, and the auditor's first round of PBC requests all hit between December 15 and January 10. Add holidays, PTO, and the one staff accountant who quit in November, and you've got the predictable burnout pattern.

The pattern looks like this:

  • October: Auditors send a "preliminary" PBC list. Controller skims it, files it, plans to deal with it after Q3 close.
  • November: PBC list resurfaces. Now there are 60 line items. Half are recurring from last year, half are new. Nobody has assigned owners.
  • December: Walkthroughs get scheduled, then rescheduled because process owners are on PTO. Year-end close starts.
  • January: Open PBC items, walkthroughs, sample testing, and post-close adjustments collide. The team works two weekends in a row.
  • February: Repeat findings from last year resurface in the audit committee deck. Controller spends a week explaining why the same control failed twice.

If any of that sounds familiar, the fix is structural, not tactical. You're not going to grind your way out of it next year by working harder. You're going to plan your way out of it by starting earlier.

PBC List Management: Start in Q3, Not Q1

The single highest-leverage thing a controller can do is take the prior-year PBC list and start working it in September.

Here's the sequence I run:

September (Week 1): Pull last year's final PBC list. Mark every line item as one of three types:

  1. Recurring static: items that don't depend on year-end balances. Org charts, signed policies, debt agreements, lease schedules, board minutes, code-of-conduct attestations. Roughly 40 to 50 percent of a typical PBC list.
  2. Recurring dynamic: items that recur but require year-end numbers. Accrual workpapers, AR aging, inventory rollforwards, deferred revenue waterfalls.
  3. One-off: items tied to a specific event last year (acquisition, debt issuance, impairment). Most won't repeat. Document them and move on.

September (Week 2-4): Email the audit partner. Ask for the current-year preliminary PBC list, even if it's still in draft. Most firms will send it. If they won't, send them last year's list with the static items pre-filled and ask "are these still in scope?" That alone usually pulls a response.

October: Pre-populate every static item. Org chart, current bylaws, debt schedules, lease schedule with current balances, signed delegation-of-authority policy, insurance certificates, board meeting minutes year-to-date. By October 31, between 35 and 45 percent of the final PBC list should be done and uploaded.

November: Tackle the dynamic items that don't need year-end numbers, anything you can run on Q3 balances and roll forward. Stock comp expense, deferred rent, intangible amortization schedules. These rarely have material movement in Q4 unless something specific happened.

December and January: Only the genuinely year-end-dependent items remain. AP cutoff testing, year-end accruals, post-close adjustments, balance confirmations. The list that used to be 60 items is now 15 to 20.

Every line item gets the same three fields: owner, due date, status. No exceptions. If you can't name an owner, the line item doesn't have a home and it'll fall through. The status options are: not started, in progress, ready for review, submitted, accepted by auditor. Five states. No "almost done."

Run a 30-minute weekly standup with the audit team starting the second week of October. Walk the list. Anything red gets unblocked on the call. Don't email about it for the rest of the week. The standup is the unblock channel.

The Q3-to-Q1 Audit Calendar

Window Owner Workstream
September Controller Prior-year PBC review, static-vs-dynamic split, current-year list request
October Controller + IC owners Static PBC items uploaded; weekly auditor standup begins
November Controller + Sr. Accountants Dynamic items on Q3 balances; interim controls testing windows confirmed
Early December Process owners Internal walkthrough rehearsals; control documentation refresh
Mid-late December Whole team Year-end close starts; year-end-dependent PBC items begin
January Controller + Sr. Accountants Roll-forward procedures, balance confirmations, post-close adjustments
February Controller Findings discussion, remediation plans, audit committee prep

The shape of the work matters more than any single line. Notice how September through November is mostly the controller and a few process owners doing prep work that the rest of the team never sees. That's the point. By the time December hits, the team is closing books and answering targeted PBC questions, not scrambling to assemble a lease schedule from scratch.

Control Documentation: Design vs. Operating Effectiveness

This is where most findings come from, and it's almost always a documentation problem, not a control problem.

Auditors test controls on two dimensions:

Design effectiveness: does the control, as written, prevent or detect the risk it's supposed to address? This is walkthrough territory. The auditor reads the control narrative, traces a single transaction end-to-end, and asks whether the design would catch a problem if one occurred.

Operating effectiveness: did the control actually run, every time, throughout the period, with evidence? This is sample testing territory. The auditor pulls 25 or 40 transactions, asks for the evidence that the control ran on each, and counts exceptions.

Here's the trap: controllers conflate the two. They write a beautiful control narrative ("the AP supervisor reviews and approves all invoices over $10,000 before payment release"), the design test passes, and then sample testing shows that on three of 25 selected invoices, the supervisor's approval is missing or dated after the payment date. That's not a design failure. That's an operating failure. But because the documentation didn't separate the two, the finding gets written up as "control over disbursements is ineffective," which sounds far worse than it is.

Document them separately. For every key control:

  • Design narrative: what risk it addresses, who performs it, when, what evidence is generated, what the threshold or trigger is.
  • Operating evidence: where the evidence lives (system, folder, email log), how to retrieve it, who maintains the audit trail, what the population looks like for a sample period.

When the auditor pulls a sample, the operating evidence is one click away. When they ask design questions, the narrative answers them. The two conversations don't bleed into each other.

The Auditor Relationship: Frequent and Clean Beats Hostile

The single best move you can make in October is to schedule a 30-minute weekly check-in with the audit senior and engagement manager. Recurring. On the calendar. Through January.

Three rules for those calls:

  1. One named point of contact on your side. Not the controller plus the senior accountant plus the FP&A manager. One person. The auditor copies that person on every email. If the senior associate emails seven different people on your team, you'll spend two weeks deduping responses and apologizing for inconsistencies.
  2. Surface issues before they become findings. If you know a control broke twice in Q2, say so on the October call, not in January when sample testing surfaces it. Auditors hate surprises far more than they hate problems. A self-disclosed control gap with a documented remediation almost never becomes a written finding. The same gap discovered in testing usually does.
  3. When you disagree, disagree with workpapers, not tone. "We don't think that's a finding" is a fight. "Here's the workpaper showing the control ran on those three exceptions, and here's why we believe the test population was scoped incorrectly" is a conversation. The audit partner has heard every version of "we disagree" and zero of them work without documentation.

Frequent and clean is not the same as friendly. You're not making friends. You're reducing transaction cost on every email, every PBC item, every walkthrough.

The "Open Finding From Last Year" Anti-Pattern

Repeat findings are how a clean audit becomes a material weakness conversation. They're also how a controller's career stalls.

Every prior-year finding has to have a documented remediation in place by interim testing (Q3, not year-end). Not a plan. A remediation that has been operating for at least one quarter, with evidence the auditor can sample.

If you genuinely cannot remediate before interim, document why and what compensating control exists. Compensating controls are real audit currency. "We can't get our purchase order system to enforce three-bid sourcing yet, so the CFO reviews and signs off on every PO over $50,000 with a three-bid memo" is a valid compensating control. "We're working on it" is not.

The reason this matters: a single finding is a finding. The same finding two years running is a pattern. Three years running, in a SOX environment, is a material weakness. And material weaknesses are disclosed publicly, hit the 10-K, and end up in board conversations that no controller wants to be in.

If your prior-year report has open findings still listed as "in remediation" by September, that's the highest-priority work in the building. Everything else can wait two weeks.

Walkthroughs the Audit Team Will Accept

Bad walkthroughs are the controller narrating while three process owners sit silently in the room. The auditor asks a question, the controller answers, and the auditor writes "controller appeared to answer for process owner; design effectiveness inconclusive." That's a finding waiting to happen.

Good walkthroughs have three properties:

  1. One process owner does the talking. The controller is in the room as backup, not as narrator. If the process owner can't explain the control in their own words, you have a training problem, and the auditor will find it eventually.
  2. Live system demo plus a sample document plus control evidence, in one sitting. Don't make the auditor schedule three separate sessions. Pull a real transaction, walk it through the system, show the approval evidence, show the reconciliation, show the sign-off. End to end in 25 minutes.
  3. Pre-walk every walkthrough internally a week before the auditor sees it. Run the same demo with the controller playing auditor. Every gap you find is a gap the auditor would have found. Fix the gaps before the real walkthrough, not after.

The "walkthrough by committee" anti-pattern, where five people from your team are in the room and three of them keep correcting each other, is one of the fastest ways to draw a design effectiveness finding. Pick one owner. Trust them. Be backup, not lead.

SOX vs. Non-SOX: Know Which Game You're Playing

Audit prep looks fundamentally different depending on whether you're under SOX 404(b).

Private, pre-IPO, no debt covenants requiring ICFR: Financial statement audit only. The auditor opines on whether the financials are fairly stated. They walk through controls to scope their substantive testing, but there's no separate ICFR opinion, no management assertion, and no auditor attestation on internal controls. PBC list is leaner. Walkthroughs are advisory, not graded.

Public, post-IPO, accelerated filer: Full SOX 404(b). Management assertion on the effectiveness of ICFR plus auditor attestation. Controls testing year-round. Quarterly certifications. Material weakness disclosure obligations. The PBC list is roughly twice the size of a financial-statement-only audit, controls testing happens at interim and year-end, and any deficiency over a certain threshold has to be tracked, evaluated, and potentially disclosed.

Pre-IPO with S-1 in the next 18 months: This is where controllers get hurt. The instinct is to wait until S-1 drafting starts to begin SOX readiness. By then, you have nine months and an audit partner telling you that you need three quarters of remediated controls operating effectively before you can support a clean opinion. The math doesn't work.

Eighteen months of runway is the floor for SOX readiness. Twenty-four is more comfortable. Year one is scoping, narrative writing, and gap remediation. Year two is testing the controls operating effectively for the period leading into the first 10-K. If you're inside 12 months of an expected S-1 and SOX work hasn't started, that's a board-level conversation, not a controller workstream.

Knowing which game you're playing changes everything about the audit calendar. Don't run a SOX-grade prep cycle if you're a Series B private company with no debt covenants. Don't run a financial-statement-only cycle if you went public last year.

Interim vs. Year-End Testing: Push the Work Left

The most underused lever in audit prep is interim testing.

Interim testing happens in Q3 (typically October or November). The auditor selects samples on year-to-date transactions, tests controls operating through that point, runs preliminary analytics on revenue and expenses, and confirms scope. Year-end testing happens in Q1 and focuses on roll-forward procedures: confirming that controls continued to operate from the interim cutoff through December 31, plus balance confirmations, post-close adjustments, and the procedures that genuinely require year-end balances.

The more you finish at interim, the less crushes the team in January. Some controllers push back: "interim testing pulls our staff into audit work during Q3 close." That's true. It also redistributes the load. A modest hit to Q3 close (say, 15-20 hours of staff time across two weeks) saves 80-plus hours in January.

Negotiate interim scope with the audit senior in September. Anything that can be tested on YTD numbers should be tested at interim. Anything that genuinely requires year-end balances stays at year-end. The auditor wants this too. Interim testing reduces their year-end crunch and improves quality. Most firms will say yes if you ask.

The Five Diagnoses I See Every Year

When a Q4 audit goes sideways, it's almost always one of these five:

  1. Repeat finding: last year's open finding never got a real remediation. Now it's a pattern.
  2. Scope creep: the auditor expanded the PBC list mid-cycle and the controller didn't push back with workpapers showing the original scope. Two weeks of extra work appears.
  3. Walkthrough by committee: five people in the room, no clear process owner, three corrections per walkthrough. Design findings pile up.
  4. Single point of failure: one staff accountant holds the entire revenue waterfall in their head, gives notice in November, and nobody else can explain it to the auditor.
  5. Late PBC start: controller didn't open the prior-year PBC list until December. The whole calendar collapses backward into Q4.

Every one of those is preventable in September. None of them are preventable in January.

Closing

A clean audit is a calendar problem. The controllers who run weekly check-ins with their audit team starting in October, document design and operating effectiveness as separate workstreams, and finish 40 percent of the PBC list before December are the ones who finish year-end on time without burning out.

The ones who treat audit as a Q1 sprint are the ones updating their LinkedIn in February.

Pick the calendar. Run the standups. Document the controls in two halves. The rest is execution.

Learn More