The request list arrives a week or two before fieldwork: thirty or forty numbered items, a due date for each, and a note asking for everything to be uploaded to a portal. Auditors call it the request list, the information request or the PBC list, a term borrowed from external audit where it stands for “provided by client” or “prepared by client”, depending on who you ask. For the team being audited it is where most of the hours go. On a mid-sized engagement the department being audited can spend well over a hundred hours in total, and the person coordinating requests carries a third of it. Handled badly, the list swallows a month of the team’s real work and still produces a finding that “management was unable to provide” half of what was asked. Handled well, it takes a fraction of the time and quietly improves the report.
This guide is for the people answering the list. It explains what each kind of request is for, how to triage the list in the first 48 hours, the single-coordinator model and a tracker template, how to produce data extracts and sample support that are accepted first time, what is fair to negotiate and what is not, what never to send, and how responsiveness shapes the findings. A worked example follows an accounts payable team through five weeks of requests. The broader journey through an audit is in the site’s guide to what to expect during an internal audit, which also lists twenty typical items and why each is asked for.
In this guide
- The five kinds of request, and what each is for
- The first 48 hours: triage
- One coordinator, one tracker
- The request tracker: a template
- Populations and data extracts: right the first time
- Sample support: what a complete package looks like
- What is fair to negotiate
- What never to send
- Naming, versions and your own audit trail
- When requests pile up, and how responsiveness shapes the report
- Sensitive data: agree the handling before the first file
- Walkthroughs and interviews: scheduling the people requests
- When other auditors are asking at the same time
- Worked example: five weeks of requests in accounts payable
- Questions auditees ask about request lists
- Related guides
The five kinds of request, and what each is for
A request list looks like one undifferentiated pile, but it mixes five different kinds of request, and each wants a different response. Sorting the list into these five is the first thing to do with it, because the kind decides who answers, how long it takes and what “done” looks like.
| Kind | Examples | What the auditors use it for | What a good response looks like | Typical turnaround |
|---|---|---|---|---|
| Documents that already exist | Policies, procedures, organization charts, approval matrices, prior reviews | The criteria they will test against and the context for the scope | The current version, as it exists, with its date and approval | One to three days |
| Populations and data extracts | Transaction listings, user access lists, change logs, exception reports | The population they sample from and run analytics on | A complete extract straight from the system, with the parameters, record count and a control total | Three to ten days, depending on IT |
| Sample support | The evidence behind 25 selected invoices, reconciliations or approvals | Testing each item against the control | One folder per item, named by the auditors’ sample number, with every document the test needs | Five to ten days after the sample is issued |
| People’s time | Walkthroughs, interviews, observation of a process | Understanding how the process really runs | The person who does the work, booked, with the system open | Scheduled in the first week |
| Follow-up questions | “Why was this approved after payment?” “What does code 17 mean?” | Explaining exceptions before they become findings | A written answer with evidence, from the person who knows | One to two days |
The follow-up questions matter more than their size suggests. They are the auditors telling you where a potential finding is forming, and a prompt, evidenced answer is often the difference between an exception explained and an exception reported. Treat every follow-up as urgent.
The first 48 hours: triage
The most expensive mistake with a request list is discovering on day nine that item 14 meant something different from what you assumed. The fix is to read the whole list in the first two days and give every item one of five codes. The codes turn a pile into a plan, and they surface every question while there is still time to ask it.
| Code | Meaning | Next step |
|---|---|---|
| Send | The item exists and you know where | Assign an owner and a date; most can go in the first week |
| Extract | It needs a system run or IT’s help | Book IT time now; agree the parameters with the auditors before running anything |
| Clarify | The request is ambiguous, or you are not sure what would satisfy it | Ask the audit lead in writing on day one or two, with your proposed interpretation |
| Does not exist | There is no such document or report | Say so in writing, with any substitute that does exist; never create one |
| Sensitive | It contains personal, health, salary or legally privileged information | Agree the handling with the audit lead: redaction, a secure portal, viewing on site |
Send the clarifying questions as one message, not a trickle, and propose an answer to each (“for item 14 we propose the vendor master change log for January to June, as a system extract; please confirm”). Auditors almost always agree to a reasonable proposal, and a confirmed interpretation protects you if the item is later questioned. Under Standard 13.1 of the Global Internal Audit Standards the auditors are required to communicate the engagement’s objectives, scope and timing to management, so asking how an item connects to the scope is a legitimate question, not an obstruction.
One coordinator, one tracker
Teams that survive request lists well almost always do one thing the others do not: they name a single coordinator, and everything goes through that person and one tracker. The coordinator is not a gatekeeper who filters what the auditors see; performers still speak to the auditors directly in walkthroughs and interviews. The coordinator owns the logistics: who is answering what, by when, in which file, and what has been sent. Without that role, requests are answered twice or not at all, files go out in three versions, and the manager spends the fieldwork weeks chasing their own team.
| Role | Who it usually is | What they do |
|---|---|---|
| Coordinator | A senior team member who knows where documents live, not necessarily the manager | Triages the list, assigns owners, keeps the tracker, sends every file, runs the weekly status call with the audit lead |
| Item owners | The people who hold each document or know each answer | Produce their items by the agreed date, in the agreed format, and answer follow-ups |
| Data support | IT, a system administrator or a report writer | Runs extracts with the agreed parameters and documents how they were produced |
| Manager | The head of the area audited | Reviews anything sensitive before it goes, resolves conflicts over time, and escalates if the list is unreasonable |
| Audit contact | The audit lead or senior on the engagement | Answers clarifications, confirms receipt, and tells the coordinator when an item is complete |
The request tracker: a template
The auditors will keep their own log, but you need yours, because theirs records what they received and yours records what you sent, when, and why anything is late. The columns below are enough; a shared spreadsheet is fine. Use the auditors’ numbering exactly, in the tracker and in every file name and email, because a list of forty items with two hundred attachments becomes unmanageable within a week without it.
| Request # | Item (as worded by the auditors) | Code | Owner | Due | Sent | File name(s) | Status and notes |
|---|---|---|---|---|---|---|---|
| R-03 | Accounts payable procedures, current version | Send | AP supervisor | Day 3 | Day 2 | R-03_AP-procedures_v2024-11.pdf | Complete; approved Nov 2024 |
| R-07 | Invoices paid January to June, full listing | Extract | ERP analyst | Day 7 | Day 6 | R-07_paid-invoices_Jan-Jun.csv; R-07_parameters.pdf | 18,650 rows; control total agreed to the general ledger; parameters screenshot attached |
| R-11 | Vendor master change log | Clarify | Coordinator | Day 2 | Day 2 | (question) | Asked whether bank-detail changes only or all fields; auditors confirmed all fields, January to June |
| R-14 | Monthly duplicate payment review, evidence | Does not exist | AP supervisor | Day 3 | Day 3 | R-14_response.pdf | No formal review exists; explained the informal check performed by the AP clerk |
| R-19 | Payroll deductions for AP staff | Sensitive | Manager | Day 5 | Day 5 | (via portal, restricted) | Agreed redacted extract with employee IDs only |
| S-01 to S-25 | Support for 25 sampled invoices | Send | AP clerks | Day 15 | Day 14 | S-01 to S-25 folders | Two items missing receipts; explained in S-09 and S-17 notes |
The tracker is also your evidence. If a finding later says requests were answered late, the tracker shows when each was sent and which clarifications the auditors took three days to answer. It rarely comes to that, but when it does, you will want the record.
Populations and data extracts: right the first time
Data extracts cause more rework than any other kind of request, because the auditors cannot rely on a population until they are satisfied it is complete and accurate. They will test the extract the way they test any information produced by the entity: how it was generated, with what parameters, whether it ties to something outside the file, and whether anyone could have edited it. The site’s guide to IPE testing explains their side; the practical rules for yours are below.
| Send with every extract | Why the auditors need it |
|---|---|
| The report or query name and the system it came from | To know which logic produced it and whether that logic has been tested before |
| A screenshot or printout of the parameters used (dates, entities, filters) | To confirm nothing was filtered out, deliberately or by accident |
| The run date and time, and who ran it | To tie the extract to a point in time and a person |
| The record count and a control total (a sum of amounts) | To agree the extract to the general ledger or another independent source |
| The file in its native export format, not pasted into a new workbook | An untouched export is evidence; a reformatted one has to be re-verified |
| A note of anything unusual (a system change mid-period, a known data gap) | So a gap does not look like concealment when they find it |
Three habits help more than any tool. Agree the parameters with the auditors before running anything; a two-line email saves a re-run. Offer to let them watch the extract being run, or to run it themselves with read-only access, which is often the fastest route to acceptance. And never filter, sort out rows, delete columns or tidy up an extract before sending it. If the population contains records you think are irrelevant, send them anyway and explain; the auditors decide what is out of scope, and a population with rows missing cannot be relied on for anything.
Sample support: what a complete package looks like
Once the auditors select their sample, the requests become specific: the evidence behind item S-07, and twenty-four others like it. Each sampled item is tested against a set of attributes, such as authorized, approved before payment, matched to a receipt, recorded in the right period, and the package has to evidence every one. Ask the auditors for their test attributes when the sample is issued. Most will share them, and a package built to the attributes is accepted in one pass. For a sampled supplier invoice, a complete package typically looks like this.
| Document | What it evidences | Common gap |
|---|---|---|
| Purchase order, with approval | The purchase was authorized before it was made | PO raised after the invoice arrived |
| Goods receipt or service confirmation | What was billed was delivered | Receipt entered by the same person who approved the invoice |
| The invoice | Amount, vendor and date | A copy without the received date |
| The match record (PO, receipt, invoice) | The system control operated, or the override that bypassed it | An override with no approval |
| Payment record and remittance | Payment went to the vendor’s verified account, once | Payment to an account changed shortly before |
| Any exception note | Why the item differs from the norm | No note, so the exception becomes a deviation |
File each item in its own folder named with the auditors’ sample number, and put a one-line note in any folder where something is missing, explaining what and why. A missing document with an explanation is an exception the auditors can evaluate. A missing document with no explanation is a deviation, and a single deviation in a small sample can fail the whole test, as the guide to audit sample sizes explains.
What is fair to negotiate
Request lists are negotiable in their logistics and not in their substance. Dates, formats and the shape of an extract are all reasonable to discuss, and auditors expect it; the evidence standard is not. A negotiation that starts from “here is how we can give you what you need faster” almost always succeeds. One that starts from “do you really need that?” almost never does, and it gets remembered.
| Situation | Say | Do not say |
|---|---|---|
| The due date clashes with month-end close | “Items 7 to 12 need the same people who run the close. Can we send them on the 8th instead of the 3rd? Everything else stays on schedule.” | “We’re too busy right now.” |
| The extract requested would take IT two days to build | “A standard report covers the same fields except the approval timestamp. Would that plus the approval log answer the question?” | “That report doesn’t exist,” when a close substitute does |
| The request asks for every item and you think a sample would do | “There are 4,000 of these. Would the full listing now and support for your sample later work?” | “You can’t possibly need all of them.” |
| You do not understand what an item is for | “Can you tell us what item 22 will be used to test, so we send the right thing?” | Guessing, and sending the wrong thing on the due date |
| The item contains personal data | “Can we send it with employee IDs instead of names, through the portal?” | Refusing, or emailing it unprotected |
What never to send
Some things damage the audit, or your organization, more than any missing document. The first two items on this list are about integrity; the rest are about data protection, which binds the auditors too, since Standard 5.2 of the Global Internal Audit Standards requires them to respect the confidentiality and privacy of the information they receive.
| Never send | Send instead |
|---|---|
| A document created or backdated for the audit | “This does not exist”, with whatever does. A missing document is a documentation observation; a fabricated one is an integrity finding that changes how everything else you provided is read |
| An export you have edited, filtered or reformatted | The untouched export, with a note on anything you think is out of scope |
| Passwords, access tokens or your own login so the auditors can look themselves | A request to IT for read-only auditor access |
| Full personal records when a subset answers the question | A redacted or pseudonymized extract, agreed with the audit lead |
| Screenshots with no date, system or context | Screenshots showing the system, the date and the record, or the underlying report |
| Whole mailboxes or shared drives “so they can find it” | The specific items, located by you |
| Sensitive files by ordinary email | The auditors’ secure portal or an encrypted channel |
Naming, versions and your own audit trail
Name every file with the request number, a short description and, where it matters, a period or version: R-07_paid-invoices_Jan-Jun.csv, S-12_invoice-support.pdf. Never overwrite a file you have already sent; send a new version with a note of what changed, so that the auditors’ copy and yours can always be reconciled. Keep a copy of everything that leaves your team, in a folder named for the engagement, and keep it after the audit ends. The next audit will begin with the last report, the auditors will retest what was closed, and last year’s request folder is the fastest way to answer this year’s list.
When requests pile up, and how responsiveness shapes the report
Even a well-run list backs up in the fieldwork weeks, when sample support, follow-up questions and walkthroughs all land at once. Hold a fifteen-minute status call with the audit lead once or twice a week, walk the open items, agree the next dates and bundle small follow-ups into one reply. If the volume is genuinely beyond what the team can absorb while doing its job, say so early to the audit lead and, if needed, to the audit manager, with a proposed sequence. Audit functions plan hours for the auditee’s time too, and most would rather re-sequence than receive half-answered requests.
Responsiveness shows up in the report more often than auditees realize. A request log with items open for three weeks appears in the cause analysis as “management was unable to provide”, and a control that cannot be evidenced on request is, from the auditor’s chair, indistinguishable from a control that did not operate. The reverse is also true: a team that answers completely and on time, says plainly what does not exist and explains exceptions before they are asked about gets findings written about the process, not about the team. The standard behind this is simple. Under Standard 6.3 of the Global Internal Audit Standards, the board and senior management are expected to enable internal audit’s unrestricted access to data, records, information, personnel and physical properties; the practical form of that access is a request list answered well.
Sensitive data: agree the handling before the first file
Most request lists include something sensitive: salary data in a payroll audit, health information in a benefits audit, customer records in a complaints audit, legal advice in a litigation file. The auditors are entitled to what they need to do the work, and they are bound to protect it. Standard 5.2 requires them to respect the confidentiality, privacy and ownership of information, to follow the organization’s privacy and security rules, and to manage the custody, retention, release and disposal of engagement records. The practical answer is to agree the handling for every sensitive item in writing before anything is sent, and to minimize what is shared to what the test actually needs.
| Kind of data | Usual handling | Who should agree it |
|---|---|---|
| Salary and personal HR data | Pseudonymized extract with employee IDs; names only for sampled items; secure portal | HR data owner and the audit lead |
| Health or benefits information | Aggregated data wherever possible; individual records viewed on site or in a restricted folder | Privacy or legal, and the audit lead |
| Customer personal data | Masked account numbers; full records only for sampled items | The data owner and privacy |
| Legally privileged material | Do not send without legal’s decision; privilege can be lost by sharing | Legal |
| Security configurations and credentials | Configuration reports and screenshots, never working credentials | Information security |
Walkthroughs and interviews: scheduling the people requests
The requests that cost the most are the ones for people’s time, because they cannot be batched. Book walkthroughs and interviews in the first week, before the calendars fill with fieldwork and month-end, and give the auditors the people who actually do the work rather than the manager who can describe it. Brief each person on what a walkthrough is: an auditor picks a real transaction and follows it on the live system, asking what could go wrong at each step and what stops it. Make sure the system is open and the access works before the auditor arrives, which saves more rescheduling than any other preparation. The auditor’s side of the exercise is in the site’s guide to process walkthroughs, and the guide to being interviewed by internal audit covers what the questions are really for.
When other auditors are asking at the same time
Internal audit is rarely the only party asking. The external auditor, a regulator, the compliance team’s testing and the risk function’s reviews can all land in the same quarter, often asking for overlapping evidence. Two rules keep it manageable. First, send every party the same version of the same evidence; a population sent to internal audit that differs from the one sent to the external auditor raises a question neither will enjoy asking. Second, tell internal audit what the others are testing. The Standards expect internal audit to coordinate with other assurance providers and, where appropriate, rely on their work (Standard 9.5), and an audit lead who knows the external auditor already tested a control this quarter may be able to use that work instead of asking you again. The differences between the parties are set out in the guides to internal and external audit and to internal audit and compliance.
Worked example: five weeks of requests in accounts payable
This example is a composite, drawn from common situations rather than one company. A four-person accounts payable team at a mid-sized manufacturer received a request list of 34 items two weeks before fieldwork on an audit of payments and vendor master data. The AP manager named the senior AP accountant as coordinator and asked for two days to triage before committing to dates.
| Week | What happened | What went well | What went wrong |
|---|---|---|---|
| 0 | Triage: 19 items coded Send, 7 Extract, 4 Clarify, 3 Does not exist, 1 Sensitive; one email with four clarifying questions and a proposed answer to each | All four proposals accepted within a day; IT booked for the extracts | Nothing yet |
| 1 | All 19 documents sent; three “does not exist” responses sent in writing with what did exist | Every file named with the request number; tracker shared with the audit lead | One procedure turned out to be two years older than the system it described, which the auditors noted |
| 2 | Seven extracts sent with parameters, counts and control totals; six accepted | The paid-invoice extract agreed to the ledger first time | The vendor change log was filtered to bank-detail changes only, against the agreed scope, and had to be re-run: two days lost |
| 3 | Samples issued: 25 invoices and 15 vendor changes; test attributes requested and shared | Packages built to the attributes, one folder per item | Two invoices had no goods receipt on file |
| 4 | 38 of 40 packages accepted on first submission; 14 follow-up questions answered in a day on average | The two missing receipts explained in their folders, with the delivery emails that did exist | A clerk answered one follow-up with a guess, later corrected |
| 5 | Closing meeting: three findings | The three missing documents became one finding about monitoring, not three about documentation; nothing in the report mentioned responsiveness | The outdated procedure became part of a finding |
The coordinator spent about 38 hours on the list across five weeks, the rest of the team about 50 between them and IT about 9. The manager’s own time went mostly on the closing meeting and the response, which is where it should go. The two lessons the team wrote down afterwards were the ones most teams learn the hard way: agree the parameters of every extract in writing before running it, and answer follow-ups only when you know the answer. The response to the three findings is covered in the guide to writing management action plans that close.
Questions auditees ask about request lists
What does PBC stand for?
“Provided by client” or “prepared by client”, depending on who is using it. The term comes from external audit, where the audited company is the client. Internal auditors use it too, alongside “request list” and “information request”; they all mean the same list.
Can I refuse a request?
You can question it, and you should if you do not understand what it is for or if a cheaper route gives the same answer. Refusing outright is different. Internal audit’s access comes from its charter, approved by the board, and a refusal becomes a scope limitation that the auditors report. If you believe a request is outside the audit’s mandate, raise it with the audit lead and your own executive, and let them resolve it.
Do I have to create a document that does not exist?
No, and you should not. Say in writing that it does not exist and offer whatever does. If the absence is a real gap, it will become an observation either way, and one you disclosed is treated far better than one you papered over.
Why do the auditors want the whole population rather than a report of exceptions?
Because the exceptions report is itself something they have to test. A full population lets them select their own sample, run their own analytics and confirm nothing was left out; a list of exceptions produced by the process under audit cannot tell them what the process missed.
Can the auditors pull the data themselves?
Often, and it can be the fastest route. Read-only auditor access to reporting tools, arranged through IT, removes the extract step entirely and removes any question about whether the data was edited. Ask the audit lead whether they want it.
Related guides
- Being audited? — every guide for auditees and management, by stage of the audit.
- What to expect during an internal audit — the full engagement from the auditee’s side, with twenty typical requests explained.
- When internal audit interviews you — the conversations that run alongside the request list.
- Writing management action plans that close — what to do with the findings.
- How to prepare for an internal audit — the month before the list arrives.
- IPE testing — how auditors test the extracts you send.
- Audit evidence — which documents carry weight and which do not.
- Audit sample sizes — why one missing document can fail a test.
- The auditee communication pack — the notification letter and kickoff deck the list arrives with.
- How long an internal audit takes — where the list sits in the timeline.
- What not to say to your internal auditor — the phrasebook for the fieldwork weeks.
Leave a Reply