Build a Supplier Approval File

A supplier approval file should let someone who was absent reconstruct the decision. They should be able to identify the company, see which evidence was available, distinguish facts from explanations, find unresolved questions, and understand exactly what was approved. A folder full of unnamed PDFs cannot do that.

This guide is for a buyer assembling the durable record after a supplier review. It is not the approval memo itself. If you need the short document an approver reads, start with the company-report approval memo. The file described here sits behind that memo and preserves the evidence trail.

Begin with the decision, not the documents

Create a one-page cover sheet before making folders. State the proposed legal supplier, its Chinese legal name and Unified Social Credit Code, the transaction, product, currency, expected order value, payment stage, destination, and named decision owner. Add the review start date and an `evidence current to` date.

Define the decision narrowly. `Approved supplier` is too broad if the review concerned one USD 18,000 sample-and-tooling order. Write whether the file supports onboarding, a sample order, tooling, a production purchase order, a deposit, or a renewal. A later team should not reuse a limited decision for a larger or materially different exposure.

Use folders that reflect evidence roles

A practical directory has seven numbered sections: `00 Decision`, `01 Legal identity`, `02 Entity relationships`, `03 Capability and quality`, `04 Payment`, `05 Public risk and compliance`, and `06 Contract and monitoring`. Numbering keeps the order stable across a shared drive, document system, and paper binder.

Put evidence where its role is assessed, not where its file type suggests. A bank letter belongs under Payment, even though it is a PDF. A factory audit belongs under Capability, not in a miscellaneous `Reports` folder. When one item supports two sections, keep one controlled original and link to its evidence ID rather than making untracked copies.

The folder architecture should fit the actual review. ISO's guidance on documented information emphasises communication, evidence, and knowledge sharing, while allowing organisations to choose the amount of documentation that supports their processes. The useful test is not file count; it is whether the record shows what happened and why.

Give every material item a manifest row

Maintain one evidence manifest at the file root. For each material item, record an evidence ID; filename; evidence type; observed company name and USCC; source or publisher; who obtained it; retrieval or query time; the period the information represents; the decision question it supports; access restriction; and refresh date or trigger.

Separate `retrieved on` from `information as of`. A company search downloaded on 15 July may contain an annual report for the previous calendar year. A business licence photo taken today may show a change registered months earlier. The distinction is especially important when reading Chinese annual reports.

China's current enterprise-information disclosure regulation says inaccurate public information should be corrected and that before-and-after annual-report information is shown when corrected. Preserve the result used for the decision, then add a later result as a new version. Do not silently replace the historical evidence.

Name files without destroying the originals

Keep the supplier's original file and create a clearly marked working copy if you need a standard name. A workable pattern is `SUP-014_E03_business-licence_2026-07-15_original.pdf`. It joins the supplier record, evidence ID, document role, date, and state without pretending the date is the document's effective date.

Record the original filename in the manifest. For high-value or disputed matters, a checksum can show whether the retained copy later changed, but hashing every screenshot is not a substitute for source, date, and context. Never edit an original scan to make it look cleaner; store translations, annotations, and cropped reading copies as separate derivative files.

Keep four statements apart

For each important issue, write four labelled entries: observation, interpretation, supplier explanation, and open question. For example: `Observation: contract entity is Company A; beneficiary is Company B.` `Interpretation: payment would leave the contract entity.` `Supplier explanation: B is A's export affiliate.` `Open question: written relationship and payment authority not yet verified.`

This prevents a supplier's explanation from being copied into the record as a verified fact. It also stops a reviewer from treating an analyst's inference as a registry result. Where the relationship is material, apply the bank-beneficiary relationship check and retain the documents that close the gap.

Run an open-issue register

One unanswered question can be hidden across dozens of email threads. Keep a short register with the issue ID, why it matters, evidence requested, responsible owner, supplier contact, due date, blocking milestone, current status, and closure evidence ID. Use plain statuses such as `open`, `waiting for supplier`, `under review`, `accepted with condition`, and `closed`.

Tie each issue to a transaction gate. Missing factory relationship evidence might block production approval but not a low-value sample. Unconfirmed beneficiary authority should normally block the affected payment. If the evidence is ambiguous or requires legal, sanctions, laboratory, or site expertise, record the handoff and use the professional escalation boundary.

The OECD's risk-based due-diligence framework treats due diligence as an ongoing process: identify, act, track, communicate, and adjust. In an approval file, that translates into named actions and closure evidence, not a permanent `medium risk` label with no owner.

Record approval as a versioned event

The signed record should include the decision, scope, evidence-manifest version, material exclusions, open conditions, approvers and roles, approval timestamp, and expiry or review trigger. Write `approved for one sample order up to USD 3,000, no tooling, beneficiary must remain Company A` rather than `supplier approved`.

Retain the rejected and superseded decision records. A later approval should reference the earlier version and explain what changed. Contract signature, beneficiary change, order-value increase, new product category, relocation, adverse public record, ownership change, or a long period without orders can all trigger a refresh. The contract-side evidence should follow the legal-entity and authority checks, not merely point to the approval status.

Control access and retention

A supplier file may contain personal ID copies, signatures, direct telephone numbers, bank details, or staff information that is unnecessary for most reviewers. Store sensitive items in a restricted subfolder, give the broader team a redacted working copy, and record why the personal data is needed.

For organisations subject to the UK regime, the ICO's data-minimisation guidance says personal data should be adequate, relevant, and limited to the purpose. Its storage-limitation guidance recommends documented retention periods and periodic review. Apply the laws and policy relevant to your organisation; do not keep identity material indefinitely just because storage is cheap.

Test the file with a handover

Imagine the sourcing manager leaves two weeks after approving fictional supplier `Harborline Components`. A replacement opens the file before a 30% production deposit. The cover sheet says the decision covered samples and tooling only. The manifest identifies the legal company and dates every source. The open-issue register shows that the factory is related but the new beneficiary has not been verified. The approval record states that any beneficiary change reopens payment review.

The replacement does not need to reconstruct the supplier from an inbox or assume the old approval covered the new deposit. They can pause only the payment issue, preserve the rest of the work, and add a new decision version when evidence arrives. That is the standard for a usable file.

Close with a reconstruction check

Before closing the file, ask a colleague who did not perform the review to identify the supplier, transaction scope, decisive evidence, unresolved issues, conditions, approvers, and next refresh trigger. If they have to ask which PDF is current or search email for the reason behind a condition, the file is not finished.

For a broader sequence of identity, capability, payment, contract, and monitoring work, use the supplier due-diligence workflow. The approval file is its durable memory: compact enough to navigate, detailed enough to defend, and explicit about what remains unknown.