Year-end audit support: the PBC request list
Can AI work the auditor's prepared-by-client (PBC) request list? Yes for the matching: it can pair each request with the documents supplied, track what is missing and how long it has been open, and tie supplied figures to the ledger. No for what goes to the auditor, which a named person approves, and no for the representations management signs at the end.
| The pain | Each year-end the auditor sends a request list that often runs past a hundred lines: bank and custody confirmations, the investment schedule and valuation support, capital activity, fee and carry calculations, expense invoices, board minutes, side letters. The fund controller or the administrator's client team works out which document answers each line, uploads it, chases the gaps across the manager, the administrator and the portfolio companies, and checks that every schedule agrees to the final trial balance. The list changes as fieldwork starts, version control slips, and the same question arrives twice. When a schedule built from a draft trial balance reaches the auditor, the result is a second round of requests and a later sign-off. |
|---|---|
| What AI does today | Read the request list and the folder of supplied files, propose which file answers which request, and flag requests with nothing, or only part of what was asked. Extract the figures from supplied schedules and set them beside the trial balance. Draft the chase list by owner, with ageing. The boundary: AI proposes the match and reads the figures; the tie-out arithmetic and the ageing stay as formulas, and a person approves every upload. |
| Proof it's real | Vendor-claimed, one named fund user. Juniper Square launched an admin oversight agent in July 2026 that runs over 150 checks on financial statements, capital account statements and workbooks before they reach auditors or investors. The release says AI reads the documents while deterministic code does the calculations, and quotes the CFO of ApexOne Investment Partners as a user. On the auditor's side, Suralink, a request-list platform for accounting firms, added a Client Document Prescreen agent in August 2026 that tells clients when documents are missing or incorrect. Both are the companies' own claims; we found no independent measure of match accuracy on a fund audit. Newest evidence: 2026-08. |
| What it can't do | It cannot decide what the fund tells its auditor. Every upload is a statement by management, so a named person, usually the fund controller or CFO, approves it. It cannot sign the management representation letter or judge a valuation, and it cannot tell that a document is the wrong one if the file name and content look right. A supplied schedule that agrees to a draft trial balance passes the tie-out and is still wrong, which is why the trial balance version is a control. |
| The real alternatives |
|
| What you need in place | The auditor's request list in a structured form, a single folder or portal holding every supplied file, and the final trial balance with its version and date. A named owner for each request line, across the manager and the administrator, with the fund controller or CFO approving uploads. Audit files hold investor, bank and portfolio data, so the AI tool needs the same data approval as the ledger. In a group, the audit firm's portal and the finance tool stack are often chosen centrally; ask what the platform checks before upload and who sees the exception list. |
| Effort & cost |
|
| What to watch | Test the matching on last year's audit, where the auditor's final list and the supplied files are known. Count the requests it marked as answered that the auditor later reopened. Watch the trial balance version above all: a tool that ties schedules to whatever ledger extract it was given will report a clean tie-out on stale numbers. |
Prompt to try: match the auditor's PBC list to the documents supplied
The prompt reads the auditor's request list, the folder of supplied documents and the final trial balance. It returns a linked tracker that shows each request's status, its age and owner, and a tie-out of every supplied figure to the ledger.
- 1Map the sourcesPBC list, supplied files, trial balance
- 2Trace the preparationWhich ledger version built each schedule
- 3Match and reconcileRequest IDs, file names, account codes
- 4Build the linked workbookTracker and tie-out, all formulas
5. Controls (must pass)0 unexplained rowsTotals tie to 0.00100% formula-linked100% tied to documentsFour-eyes sign-offFinal trial balance versionPartial supply flaggedAgeing past due dateOpening balances agree
6. Measured over timeBack-test finds every known difference0 corrections after sign-offCycle time vs manualRolls forward with 0 manual edits
Before you start:
- Use your firm's approved AI tool, not a personal account.
- Mask investor names and any data your policy keeps out of AI tools.
- Replace the parts in [brackets] before you run it.
- Give it the final trial balance, not a working draft, and note its version and date.
You are helping a fund controller manage the year-end audit of [fund] for the year ended [year-end date]. A human reviewer checks everything you produce. You do not send anything to the auditor, you do not mark a request as answered, and you do not change a figure in the ledger.
I attach:
- Request list: [the auditor's PBC list, with request number, description, number of items asked for, owner, date requested, due date and the auditor's current status for each request]
- Supplied documents: [the folder or portal export of the files supplied so far, with file names and upload dates]
- Trial balance: [the final year-end trial balance and the general ledger detail for the accounts in scope]
- Prior year: [last year's audited financial statements, for opening balances]
Work through the six steps below. Show the result of each step before you move on.
STEP 1. MAP THE SOURCES
For each file, record: who produced it; the as-at date it states (not the date it was sent); the currency; what one row or section represents; the fields that identify a request, a document and a ledger account; the value fields and how each is labelled; and any subtotals, hidden rows, merged cells or footnotes that change how it should be read. Where the files differ in as-at date, period or currency, list each difference and say how you will handle it: convert at an FX rate from the Inputs tab with its source, or compare like periods only. Stop and ask me only if a difference means two figures cannot validly be compared.
STEP 2. TRACE THE PREPARATION
For each supplied schedule, say who prepared it, the period and as-at date it covers, and which trial balance version it was built from, where the schedule states it. Note any schedule whose totals suggest a different ledger version, and any document that covers a different entity or period from the request. For each request, say what it asks for: one document, a set (for example every bank confirmation), or a schedule with support.
Label each statement "stated in the file" or "my inference".
STEP 3. MATCH AND RECONCILE
3a. Keys. List the identifiers in use: request number, file name or document reference, ledger account code, bank or custody account number (masked). Say which link a request to a document and a document to an account.
3b. Names. Where no shared identifier exists, describe how the request describes the item and how the file names and document titles describe it: abbreviations, entity names, period labels.
3c. Standardise. Write numbered rules for request descriptions, file names and account names, and apply them in new columns, keeping the original text.
3d. Map. Build a mapping table: request number, supplied document, ledger account where relevant, match method ("shared reference", "standardised name" or "suggested, needs review"), reason. A suggested match is never confirmed.
STEP 4. BUILD THE LINKED WORKBOOK
Build an .xlsx file with these tabs, in this order:
- Index: a link to each tab, one line on what it holds, the as-at date, and the steps to refresh the workbook during fieldwork and next year.
- Inputs: year-end date, as-at date of the tracker, the trial balance version and its date, the status categories ("Not started", "Partly supplied", "Supplied", "Reopened by auditor"), the ageing bands in days and the escalation threshold in days past the due date, the owner list; plus the as-at date of each source file, with any differences between them and how each is handled; any FX rates needed, with their source and date, and the tolerance for agreement with documents (0.00 wherever exact agreement is required). Each value carries its source beside it, and every formula that needs one points here.
- _Source tabs: each file exactly as received, one tab per file. Never edit these tabs.
- Map: the mapping table from step 3d, with the item of the request each document answers (for a set, which item, for example which bank confirmation). For each suggested match, the person who confirmed it and the date.
- Requests: one row per request, as given by the auditor: request number, description, items asked for (the count the request states, or the count you read from its description, labelled as such), owner, date requested, due date and the auditor's status, including any request the auditor has reopened.
- Supplied: one row per supplied document: file name, upload date, entity, period, the request it is mapped to, the trial balance version stated on the schedule (or "not stated"), a version check against the Inputs tab as a formula, the page reference for each figure read from it, the preparer, a ready-for-upload flag, the approver, the approval timestamp and the upload timestamp, and, for a schedule with a different or unstated version, the person who confirmed the version and the date of that confirmation (approver, approval, upload and version confirmation columns are filled by people, never by the model). Each row carries its source document and the page, cell or row reference for each figure.
- Tracker: one row per request. Documents mapped, items asked for, items supplied, status, owner, date requested, due date, days open at the as-at date, days past due and ageing band are formulas against the Requests, Supplied, Map and Inputs tabs. Items supplied counts the distinct items of the request mapped on the Map tab. Status reads from the categories on the Inputs tab: "Reopened by auditor" wherever the auditor's status on the Requests tab says so, otherwise "Supplied" only when items supplied equals items asked for, "Partly supplied" when at least one item is supplied, and "Not started" when none is.
- TieOut: one row per figure in a supplied schedule that maps to a ledger account. Schedule figure, ledger account, the account currency as the trial balance states it, ledger balance, difference and status are formulas. Status reads "Agrees" or "Check". For each opening balance in a schedule, the prior-year audited closing balance (from the prior-year statements _Source tab), the opening difference and the opening status are also formulas, with a reason column for any opening difference (filled by a person). Each row carries its source document and the page, cell or row reference for each figure.
- Exceptions: a formula-driven list of every request not "Supplied", every request past due, every unrequested document, every "Check" on the TieOut tab, every schedule built from a different trial balance version or with its version "not stated", every opening difference and every unconfirmed match. It also lists every failed control and open query. Each row carries its type ("not supplied", "past due", "unrequested", "tie-out check", "version mismatch", "version not stated", "opening difference", "unconfirmed match", "failed control", "open query" or "timing difference"), a description, its reason, its owner, status ("open" or "closed"), expected clearing date (for a past-due request, the expected supply date) and the approver's sign-off.
- Checks: the controls in step 5.
- KPIs: the measures in step 6.
- _Log: the audit trail in step 6.
Every derived number is a formula that leads back to a _Source tab or the Inputs tab. Nothing is typed in as a value. Use Excel tables and XLOOKUP or INDEX/MATCH. Wrap lookups in IFERROR and show "Not found", never zero. Dates as yyyy-mmm-dd, negatives in brackets, units in every value header, header rows frozen, no decorative formatting.
STEP 5. CONTROLS (EVERY ONE MUST PASS BEFORE SIGN-OFF)
On the Checks tab, write each control as a formula that returns TRUE or FALSE, with the count or difference beside it. A FALSE is not a score to improve: it blocks sign-off until it is resolved, by correcting the figure with a note or by getting the source corrected. An explanation alone does not clear it. The only item that may stay open at sign-off is a timing difference with an expected clearing date: it is listed by name on the Exceptions tab as a reconciling item and re-checked next period. A document tie-out failure is never a timing difference and can never be carried. Show every FALSE at the top of the Index tab under "Checks failing".
a. Complete: every request on the auditor's list appears once on the Tracker tab, and every supplied document is mapped to a request or listed on Exceptions as "unrequested". Target: 0 unexplained rows.
b. Totals tie: the count of requests by status on the Tracker tab sums to the number of requests on the list (target: a difference of 0). Separately, the ledger balances on the TieOut tab equal the trial balance _Source tab for the same accounts, by currency (target: a difference of 0.00).
c. Formula-linked: every calculated cell is a formula (test with ISFORMULA), and there are no #N/A or #REF errors. Target: 100%.
d. Tied to documents: every figure on the TieOut tab cites its schedule, page and ledger account, and every mapped document on the Supplied tab cites its file name. Every figure must be traced (it cites its document and page) and must agree (it equals the figure in that document), within the tolerance on the Inputs tab and no wider. Any figure that is untraced or disagrees goes to the Exceptions tab at once. If the document itself looks wrong, for example a bank confirmation that disagrees with the ledger, raise it as a query; never change the workbook to make it agree. Target: 100%.
e. Matches confirmed: count the rows matched by shared reference, by standardised name and by suggestion. Target: 0 suggested matches left unconfirmed at sign-off.
f. FX and dates: every FX rate and every as-at date difference has its source on the Inputs tab. Target: 100%.
g. Trial balance version: every supplied schedule on the Supplied tab states the trial balance version on the Inputs tab. A schedule with a different version, or "not stated", is on Exceptions to be rebuilt or confirmed before it goes to the auditor.
h. Partial supply: no request reads "Supplied" while any item it asks for is unmapped, for example one missing bank confirmation in a set.
i. Ageing: every request past its due date by more than the escalation threshold on the Inputs tab is on Exceptions with its owner and an expected supply date.
j. Opening balances: on the TieOut tab, every opening balance in a supplied schedule equals the prior-year audited closing balance within the tolerance on the Inputs tab, or the opening difference is on Exceptions with its reason.
k. Approval before upload: every document on the Supplied tab with an upload timestamp has a ready-for-upload flag, an approver who is not the preparer, and an approval timestamp earlier than the upload timestamp. HUMAN STEP: a person approves each upload; the model never marks a request as answered.
l. Open exceptions: count the Exceptions rows that are not closed, leaving out only named timing differences with an expected clearing date. Target: 0.
m. Four-eyes: the _Log names the preparer and the approver, who must be different people, and the approver signs off every Exceptions line.
STEP 6. REUSABLE, AUDITABLE AND MEASURED
- Reusable: during fieldwork and next year, a person replaces the _Source tabs and updates the Inputs tab, and every other tab recalculates. Keep the Map tab so confirmed matches carry forward to next year's list.
- Auditable: on the _Log tab, list each source file (name, producer, as-at date, date received, row count, control total), every rule and match you applied with the reason, every assumption, every upload with its approver, and who prepared and approved. Never overwrite source data. A correction goes in a separate column with a note.
- Measured: add a KPIs tab that the team fills in each audit: back-test recall (run on last year's audit with known answers; share of known gaps, reopened requests and tie-out differences found; target 100%, and do not adopt the workbook below that); requests answered first time with no reopening; items flagged that turned out fine; corrections made by the reviewer before sign-off; corrections found after sign-off (target 0); manual edits outside the Inputs and _Source tabs at refresh (target 0); and cycle time in days from the request list to the last request supplied, against the manual baseline.
If your tool cannot create an .xlsx file, give me each tab as a table plus the exact formula for the first row of every calculated column.
At the end, give me the number of requests, the number supplied, partly supplied and not started, the number past due by owner, the number of tie-out differences, the result of every check, and a list of anything you were unsure about.What good output looks like:
- Every request shows its status, owner and days open, all by formula.
- A request asking for every bank confirmation reads "Partly supplied" until the last one is mapped.
- A schedule built from an earlier trial balance version is flagged even when its own totals add up.
- Every control on the Checks tab reads TRUE before sign-off. Only a timing difference with an expected clearing date is carried as a reconciling item.
How to know it worked:
- Back-test: run it on last year's audit, where the final request list and the reopened items are known. Adopt it only if it finds every known gap and tie-out difference.
- After sign-off: no corrections are found later, and the auditor reopens no request the tracker marked as supplied.
- Over time: fewer reviewer corrections and false flags, and a shorter time from the request list to the last item supplied.
Who signs off: The fund controller approves each upload to the auditor, and the CFO or the board signs the financial statements and the representation letter. Where the administrator prepares the statements, its client team answers its own requests and the controller reviews them. The workbook is the working file, not the record.
In practice: run it on last year's request list first and count the requests the auditor reopened. Most reopened requests trace to a partial supply or a stale ledger version, and both are visible in the tracker before anything is uploaded.
Questions operators ask
Will our auditor accept documents matched by AI?
The auditor relies on the document, not on how it was found. What matters is that management approves each upload and that the document is the right version. Keep the approver's name and date for every upload; that record answers the question if the auditor asks.
Our administrator prepares the financial statements. Do we still need this?
Possibly not. Ask the administrator for its PBC tracker and its tie-out to the final trial balance, and check the items only the manager holds, such as side letters, board minutes and valuation support. The prompt is useful as a check on a sample of the administrator's responses.
How much time does it save?
The saving is in matching files to requests and chasing gaps, which takes most of the controller's hours in the weeks before fieldwork. The auditor's questions and the valuation discussion still take the same time, so measure the days from the request list to the last item supplied, not the hours spent uploading.
Related: NAV break and reconciliation-exception triage and the Fund AI desk.