← Back to journal
Finance Operations

PBC List Audit Prep: Reconciliations Auditors Accept

The year-end PBC list for balance sheet reconciliations: what to provide for each account, what the auditor checks, why recs get sent back, and a 12-point check to run before you submit.

PBC reconciliations your auditor will accept: if the auditor can't re-perform it, it isn't done

Most PBC reconciliations that come back from the auditor are not wrong. They are unprovable: the balance does not tie to the trial balance, the sign-off has no date, or the report behind it has no visible parameters. This is a PBC list audit guide for year-end balance sheet reconciliations: what to provide, and what gets each one accepted on the first pass.

TL;DR: A PBC (prepared by client) reconciliation is accepted when it ties to the final trial balance and to an external or subledger source, shows preparer and reviewer sign-off with dates, supports every reconciling item, explains aged items, and shows how each supporting report was produced so the auditor can test completeness and accuracy.

What is a PBC list in a year-end audit?

A PBC list is the auditor's request list of schedules and documents the company prepares and hands over for the audit. PBC usually stands for "prepared by client"; some firms say "provided by client." Either way, the work is yours and the testing is theirs.

For a controller, the heaviest block is the balance sheet reconciliations, because nearly every account the auditor tests starts from one. A clean rec gets sampled. A weak one gets sent back, or the auditor builds their own schedule and asks more questions.

For calendar-year companies, year-end audit work runs from late Q4 through Q1. Fix the reconciliations before the list arrives, not after the first round of comments.

What makes a reconciliation "auditor-accepted"?

An auditor-accepted reconciliation is one the auditor can re-perform from what you gave them, without asking you a question. In practice that comes down to five things.

  • It ties twice. The ending balance agrees to the final trial balance for the period, and to an independent source: a bank statement, a subledger, a lender statement, a cap table.
  • It is signed and dated. A named preparer and a named reviewer, each with a date. A reviewer date before the preparer date, or after the audit request, is a finding waiting to happen.
  • Every reconciling item has support. Outstanding checks tie to the check register, deposits in transit to the January statement, adjustments to a posted journal entry.
  • Aged items are explained. Anything sitting more than 60 or 90 days (use your own policy threshold) has a note on what it is and when it clears or gets written off.
  • The reports behind it are testable. The auditor can see the system, report name, parameters (date range, entity, status filters) and run date.

The last point is the one teams skip. Under PCAOB AS 1105, Audit Evidence, when an auditor uses information produced by the company, they must test its accuracy and completeness (or the controls over it) and evaluate whether it is precise and detailed enough. For private company audits, the AICPA's SAS No. 142 rewrote AU-C 500 and, as the Journal of Accountancy reported, became effective for periods ending on or after December 15, 2022; it asks auditors to evaluate the relevance and reliability of information whatever its source. Information produced by the entity (IPE) is any report or data your systems generate that the auditor relies on as evidence. An AR aging exported with no visible parameters is IPE the auditor cannot test, so they will ask for it again.

PCAOB amendments on technology-assisted analysis, effective for fiscal years beginning on or after December 15, 2025 (PCAOB), point the same way: show how the data was produced, not just the output.

Which reconciliations belong on the year-end PBC list?

This is the balance sheet block most auditors of VC-backed and PE-backed companies will ask for. Your list may differ by industry and by the auditor's risk assessment.

Table of year-end PBC reconciliations by account showing what to provide, what the auditor checks, and the common rejection reason
  • Cash and bank: provide the rec for every account, Dec and Jan statements; auditor checks ties to TB and statement, clears reconciling items in January; common rejection: outstanding items with no January clearing support.
  • Accounts receivable: provide aging tied to GL, subsequent receipts, allowance calc; auditor checks aging total equals GL, tests receipts after year-end; common rejection: aging run on a different date or with filters hidden.
  • Accounts payable: provide AP aging tied to GL, January disbursements list; auditor checks search for unrecorded liabilities; common rejection: aging excludes unapproved or on-hold bills.
  • Accrued liabilities: provide schedule by accrual with basis and January true-up; auditor checks the estimate method and later invoices; common rejection: round-number accruals with no calculation.
  • Prepaid expenses: provide roll-forward with invoice, term and monthly amortization; auditor checks the amortization math and period; common rejection: balances still on the books after the term ended.
  • Fixed assets: provide roll-forward (additions, disposals, depreciation) tied to register; auditor checks additions to invoices, depreciation recalc; common rejection: register total does not match GL.
  • Debt: provide lender statements, amortization schedule, covenant calc; auditor checks principal, accrued interest, classification; common rejection: accrued interest not tied to the lender statement.
  • Equity and SAFEs: provide cap table, equity roll-forward, SAFE and note agreements; auditor checks cap table to GL, instruments to board approvals; common rejection: cap table as of a different date than the GL.
  • Deferred revenue: provide roll-forward by contract (billings, revenue recognized); auditor checks contract terms against the recognition schedule; common rejection: roll-forward does not tie to invoicing or revenue.
  • Payroll liabilities: provide payroll register tie-out, January tax deposits; auditor checks payroll register to GL and deposits; common rejection: benefits and taxes lumped into one unsupported line.

Yoraito is building reconciliations that carry their own evidence. Join the waitlist for early access.

What does a clean tie-out look like?

Here is a bank reconciliation as the auditor would want to receive it. The numbers are illustrative.

  • Balance per bank statement, Dec 31: $1,482,300.00
  • Less outstanding checks (3 items, all cleared by Jan 9): ($41,250.00)
  • Add deposit in transit (cleared Jan 2): $18,900.00
  • Adjusted bank balance: $1,459,950.00
  • Balance per GL account 1010 on the final TB: $1,460,200.00
  • Less December bank fee not yet recorded (JE posted, dated Dec 31): ($250.00)
  • Adjusted book balance: $1,459,950.00
  • Unreconciled difference: $0.00
  • Prepared by: named preparer, Jan 6. Reviewed by: named reviewer, Jan 8.

Each line points to something the auditor can pick up: the statement, the check numbers and clearing dates, the journal entry. Nothing is a plug.

For subledger accounts, the tie-out can be shown as a query, with the parameters in plain view:

-- Illustrative: AR aging vs GL control account, as of 2026-12-31
SELECT
(SELECT SUM(open_amount)
FROM ar_open_items
WHERE as_of_date = '2026-12-31'
AND status IN ('open','partial')) AS aging_total,
(SELECT SUM(debit - credit)
FROM gl_lines
WHERE account = '1200'
AND posting_date <= '2026-12-31') AS gl_balance;

The auditor can read the cutoff and the status filter directly, which answers the completeness question before they ask it. In Yoraito, each approved match rule is SQL your team and your auditor can read and rerun. Whatever tool you use, if an automated or AI-assisted match produced a reconciling item, the rule behind it should be visible and a person should have approved it. We cover the controls side of that in why finance teams are still wary of giving AI control.

Why do auditors send reconciliations back?

The rejections are predictable. Most fall into one of these:

  • The rec ties to a preliminary TB, and entries posted afterward changed the balance.
  • The support report was run on a different date, or with filters the auditor cannot see.
  • The reviewer sign-off is missing, undated, or done by the preparer.
  • Reconciling items are summarized ("timing differences, $12,400") with no detail.
  • Old items carry forward month after month with no explanation.
  • A spreadsheet has hardcoded balances where a link or a source reference should be.

Every one is fixable before submission with a review step that asks: could someone outside the team re-perform this? A reviewer who signs without checking support is not a control, a point we make in AI journal review needs governance, not just automation.

What should you check before submitting reconciliations?

Run this pre-submission check on every balance sheet reconciliation before it goes into the PBC folder.

Pre-submission checklist for year-end PBC reconciliations with twelve checks
  • Balance ties to the final trial balance, and the TB version or date is noted.
  • Balance ties to the external statement or subledger, with the source attached.
  • Unreconciled difference is zero, or explained and below your documented threshold.
  • Every reconciling item has support: item-level detail, not a summary.
  • Outstanding items show January clearing evidence where it exists.
  • Items older than your policy threshold have a written explanation and a plan.
  • Any adjusting entry is posted, and the entry number is on the rec.
  • Supporting reports show system, report name, parameters and run date.
  • Spreadsheets reference sources; no hardcoded plugs.
  • Preparer and reviewer are different people, both named, both dated.
  • Reviewer date is after the preparer date and before submission.
  • File names and folder structure match the auditor's PBC item numbers.

A reconciliation is complete when an outsider can re-perform it from the file alone. That is the standard to hold yourself to, and it is the one the auditor applies.

Frequently asked questions

What does PBC stand for in an audit?

PBC usually stands for "prepared by client," and some firms use "provided by client." It refers to the schedules and documents the company prepares for the auditor, such as reconciliations, agings, roll-forwards and contracts. The auditor then tests them.

When will my auditor send the PBC list?

It usually arrives a few weeks before fieldwork, after planning. Ask for it early and ask whether the prior-year list will be reused, so you can start on the reconciliations first.

Do I need to show report parameters for every supporting report?

For any report the auditor relies on as evidence, yes, show how it was produced. Auditing standards (AS 1105 for PCAOB audits, AU-C 500 as amended by SAS 142 for private companies) require auditors to evaluate the reliability of company-produced information. Parameters, run date and source let them do that without asking you again.

Can AI-assisted reconciliations be used for the audit?

Yes, if the auditor can test them like any other company-produced information. That means the matching logic is visible, exceptions are documented, and a named person reviewed and approved the result. A match with no readable rule behind it will draw more questions, not fewer.

What is the most common reason reconciliations get sent back?

A frequent cause is a tie-out problem: the rec agrees to a preliminary trial balance or to a report run on a different date. Lock the final TB, rerun support as of that date, and note both on the rec.

Ready for the auditor's questions?

Reconciliations get accepted when the evidence travels with them: ties, dates, support, parameters. For how finance leaders are weighing trust in AI output this year, read our 2026 state of trust in finance AI. If you want early access to Yoraito, where every match carries a readable rule, join the waitlist.