Audit data preparation checklist

Executive Summary

An audit stalls or races almost entirely based on preparation, not analysis. The recurring failure is not a hard finding, it is a missing input: a superseded rate card mistaken for the current one, a vendor statement that does not match the AP ledger period, a contract stored as a scanned PDF with no searchable rate table. Each gap forces a pause to chase down a document, and the pause compounds when the same gap repeats across a dozen vendors.

The fix is mechanical, not analytical: assemble a defined set of documents and exports, in a defined shape, before testing begins. That means the current, fully executed contract for each vendor in scope, an invoice-level export covering the full audit period, the corresponding vendor statements, and the vendor master record used to route those invoices.

What changes when this is done first: the audit tests invoices against terms instead of spending its early days locating terms. A checklist forces that sequencing. It does not replace judgment about what counts as a discrepancy, but it removes the excuse for not testing every invoice in scope.

1. What documents does an audit data preparation checklist require?

A complete set has four layers: the current, fully executed contract for each in-scope vendor, including every amendment and rate addendum; an invoice-level export from the ERP covering the full audit period; the matching vendor statements for the same period; and the vendor master record showing how each vendor is coded and routed. Missing any one layer forces the audit to pause mid-test to track down a document, which is the single largest cause of delay.

Contracts have to be current, not the version signed at onboarding. A master agreement without its amendments understates the rate the vendor is actually entitled to charge, and testing against it produces false findings in both directions.

The invoice export needs line-level detail, not header totals. A summary export hides the surcharge line, the accessorial charge, and the rebate credit that the audit exists to test.

Vendor statements matter because they show what the vendor believes it billed, which is not always what the ERP shows as paid. A gap between the two is itself a finding before any contract term is applied.

The vendor master record explains why an invoice was coded the way it was, which matters when the same vendor appears under two different vendor IDs.

• Fully executed contracts: Base agreement plus every amendment, rate addendum, and side letter, dated and version-labeled.
• Invoice-level export: Line detail for the full audit period, including surcharge, accessorial, and credit memo lines, not header totals.
• Vendor statements: The vendor's own record of what it billed for the same period, for reconciling against the ERP.
• Vendor master record: How each vendor is coded, which entity or location it bills against, and whether duplicate vendor IDs exist.

2. How far back should the invoice period go?

The invoice period should match the contract's current rate term, not an arbitrary lookback. If a rate card has been in effect for 12 months, pull 12 months of invoices against it; if a rate changed mid-year, split the export at that date so each period is tested against the rate that actually applied. Testing a full year against a single rate card that only applied for part of it produces findings that are really data errors.

A rate change midyear is common enough that the export has to account for it explicitly. Splitting the period at the effective date of each rate version means every invoice is tested against the rate that was actually in force when it was issued, not the rate in force today.

Contract renewal dates matter for the same reason. An invoice issued a week before renewal should still be tested against the prior term, not the new one, unless the amendment states an earlier effective date.

Where the audit period covers more than one fiscal year, keep the export split by year so recovery amounts can be reported against the period they belong to rather than as one undifferentiated total.

3. Which invoice fields actually matter for testing?

An export built for accounting, not audit, drops fields the audit needs: the purchase order or contract reference, the accessorial or surcharge code, the unit of measure, and the period the charge covers. Without these, a matching exercise degenerates into re-reading PDFs one at a time. Ask the ERP export to include every charge line, its code, its date range, and the contract or PO it was billed against, before the audit period is pulled.

A total-only export can hide a surcharge that was billed correctly in month one and never removed once its trigger condition ended. Line-level detail with charge codes and date ranges is what makes that visible without opening the underlying invoice image.

Unit of measure matters because a rate card quoted per hundredweight is not directly comparable to an invoice billed per pallet. Reconciling the two without the unit field recorded is guesswork.

The PO or contract reference field lets the audit tie each invoice line back to the specific rate schedule that should govern it, which is the actual test being performed.

4. How should vendor statements be reconciled before testing begins?

Sort both the ERP export and the vendor statement by invoice number and date, then flag anything on one side without a match on the other. An invoice on the statement but not in the ERP suggests an unrecorded liability; an invoice in the ERP but not on the statement suggests a payment the vendor no longer recognizes, both worth resolving before contract-term testing starts, not after.

This reconciliation is a data-quality step, not the audit itself. Its purpose is to confirm that what gets tested against the contract is a complete and accurate record of what was actually billed and paid.

Doing it first means any unmatched item is caught early, while it is still cheap to trace, rather than surfacing later as an unexplained variance in the final recovery total.

Where the vendor statement and ERP cover different date ranges, align them to the shorter overlapping period rather than padding either side, so the comparison is genuinely apples to apples.

5. What should you do about missing or unreadable contracts?

A scanned contract with no searchable rate table still counts as missing for audit purposes: someone has to manually transcribe every rate, tier, and surcharge clause before testing can start. Flag these early, request a clean copy from the vendor or the contract owner, and if none exists, note the gap explicitly in the audit scope rather than testing invoices against an assumption of what the rate should be.

A missing contract does not mean the invoice is untestable forever. It means the invoice cannot be tested against contract terms until the terms are recovered, so it should sit in a separate queue rather than being skipped silently.

Where a vendor cannot produce a current signed copy, that itself is worth recording. It suggests the vendor relationship, not just the invoice, needs a closer look.

Transcribing a scanned rate table into a structured format is worth the time even outside an audit, since the same table will be needed again at the next renewal or the next review.

6. Can this checklist be reused for a recurring review, not just a one-time audit?

Yes. The same four document layers, contracts, invoice export, vendor statements, and vendor master, are what a recurring review needs each cycle, so building the pull process once as a repeatable export and file structure saves the reassembly work every quarter. The difference between a one-time audit and a recurring review is cadence, not the underlying data requirement.

A one-time audit and a standing review draw on the same inputs because the test is the same: does the invoice match the contract. What changes is how often the pull happens and how quickly a gap gets acted on.

Building the export as a saved, repeatable query rather than a one-off pull is the practical difference between a checklist used once and one used every cycle. It also makes it easier to compare one period against the next using the same fields.

A team weighing whether to run this as a periodic exercise or move to something that checks every invoice as it arrives is deciding on cadence, which is a separate question from what data to prepare.

For the wider pattern this sits inside, start with the margin drift guide.

7. Frequently Asked Questions (People Also Ask)

What is the minimum set of documents needed to start an audit?

The current, fully executed contract for each vendor in scope, a line-level invoice export for the audit period, matching vendor statements, and the vendor master record. Starting without any one of these means pausing mid-audit to track it down.

Do I need the original signed contract or is a summary enough?

The original, fully executed contract with every amendment attached. A summary or an internal memo about the terms is not sufficient because it may omit a rate change, a rebate clause, or a surcharge schedule the invoice needs to be tested against.

How do I handle a vendor with multiple contracts across locations?

Pull every active contract for that vendor and map each invoice to the specific location or entity it was billed under. Testing all invoices against a single contract when several apply produces false results for whichever locations are covered by a different agreement.

What if the ERP export does not include a contract or PO reference field?

Request the export be rebuilt with that field included before starting. Matching invoices to contract terms without a reference field means manually tracing each line, which is slow and error-prone across any meaningful invoice volume.

Should credit memos be included in the invoice export?

Yes. Credit memos show whether a known overcharge or rebate was already resolved. Leaving them out of the export risks counting an already-credited item as an open finding.

How do I know if a contract I have is actually the current version?

Check the amendment list and effective dates against the vendor's own records or the vendor statement period. A contract with no amendments on file for a long-running vendor relationship is worth confirming rather than assuming complete.

What is the right file format for the invoice export?

A structured, line-level format such as a delimited file or spreadsheet export, not a PDF or scanned report. Testing requires sorting and filtering by fields like date, charge code, and vendor, which a structured export supports and a PDF does not.

Does this checklist apply to every vendor category the same way?

The four document layers apply across categories, but the specific fields worth pulling vary. Freight needs lane and accessorial detail; contract labor needs rate tier and hours; maintenance needs scope and calibration schedules. The underlying preparation principle stays the same.

What should we do if a vendor refuses to provide a current contract copy?

Document the refusal and proceed with whatever version is on file, noting the gap explicitly in the audit scope. Testing against an unconfirmed contract version should be flagged as provisional rather than presented as a confirmed finding.

How long does data preparation usually take before testing can start?

This varies by how organized the vendor files already are, and there is no dataset here to state a typical duration. The practical driver is how many contracts require manual transcription versus how many are already in structured form.