The Buying-Group Evidence Ledger: Requested, Provided, Accepted, or Unresolved

Who this template is for

This template is for B2B teams whose offers must be evaluated through technical documents, certifications, quality records, commercial responses, cybersecurity materials, test results, or other proof. It is especially useful when several stakeholders ask for different evidence. BC-09 helps anticipate what each role may need; this article records the actual requirement, evidence object, and disposition. It does not manage follow-up sequences or pipeline stages.

Contents

1 Separate an evidence need from an evidence object 2 Use controlled evidence lifecycle states 3 Capture the fields that make evidence usable 4 Preserve source, scope, version, and confidentiality 5 Record who can evaluate and accept the evidence 6 Calculate ledger coverage without inventing approval 7 Illustrative example 8 Common mistakes 9 What this does not mean 10 Common questions 11 Sources and methodology

1. Separate an evidence need from an evidence object

An evidence need is the requirement a stakeholder wants satisfied. An evidence object is the document, answer, test, record, or decision supplied in response. They are not interchangeable. "Provide quality proof" is too vague for a ledger. A usable requirement might be: "For the Plant A washdown application, provide a current certificate issued by an accepted body covering product family X and standard Y." The response object then needs an identifier, issuer, version, issue date, scope, and link or controlled location. The distinction matters because one object may answer several needs, and one need may require several objects. A product datasheet may support a dimensional requirement but not a quality-system certification. A security questionnaire may be delivered but still lack the architecture attachment the evaluator specified. Formal procurement illustrates this separation. FAR Part 9 addresses responsibility and qualification of prospective contractors, while FAR Part 46 addresses quality assurance, inspection, and acceptance. These are distinct federal acquisition functions. They do not prove that a private buyer follows the same process, but they show why "supplier approved" and "product accepted" should not be one undifferentiated status. Each ledger entry begins with the full decision scope: account or site, application, purchase situation, relevant decision context, and evidence date. Evidence for one product family, facility, legal entity, or period must not be silently reused for another.

2. Use controlled evidence lifecycle states

SellersGPT recommends the following states: State Meaning What it does not mean requested A material requirement and requester are recorded Evidence exists provided A specified object was delivered to the named recipient It was reviewed or accepted verified Authenticity, completeness, and relevant scope were checked The deciding authority accepted it accepted The authorized evaluator or decision process recorded satisfaction The whole purchase is approved State Meaning What it does not mean rejected The authorized process found the evidence insufficient or noncompliant The account can never qualify under another scope unresolved Clarification, missing proof, contradiction, or authority remains open Failure or acceptance superseded A later controlled version replaced the object The old record may be deleted without retention review Add not_applicable only when an approved rule establishes that the requirement does not apply to this exact decision scope. Silence is unresolved, not accepted. A stakeholder saying "looks fine" may be useful context, but it is not formal acceptance unless that stakeholder has relevant authority and the statement clearly covers the requirement. Public-sector bid guidance makes state distinctions concrete. The CanadaBuys checklist for preparing a bid explains mandatory criteria, certifications, security requirements, and complete submission. It also notes that evaluation is based on the bid's content rather than assumed prior knowledge. That guidance applies to Canadian federal tendering; use it as an example of explicit evidence requirements, not a universal private-sales rule.

3. Capture the fields that make evidence usable

The minimum ledger contains: Field Required content Evidence ID Stable identifier, not a filename alone Decision scope Account/site, application, purchase situation, context, date Requirement Exact question or pass condition Requester and functional role Person/team and role in this decision Acceptance authority Person, team, process, or unknown Evidence object Document, response, test, filing, or record supplied Source and issuer Who created it and how origin was checked Version and effective period Revision, issue date, expiry, and covered period State and state date Controlled lifecycle state with timestamp Disposition note Accepted scope, rejection reason, or unresolved point Confidentiality boundary Who may access, forward, or quote it Owner and review trigger Internal accountability and next review event Do not use a free-text status such as "done." It hides whether the item was merely uploaded, reviewed for completeness, accepted by an evaluator, or superseded. Preserve the actor and date for every state change. FAR Part 15 distinguishes evaluation factors, proposal evaluation, exchanges, source-selection decisions, and documentation in negotiated federal procurement. That separation supports a core ledger rule: the person who receives evidence may not be the person who evaluates it, and the evaluator may not hold final authority.

4. Preserve source, scope, version, and confidentiality

Evidence quality is purpose-specific. The U.S. Government Accountability Office describes data reliability in terms of accuracy, completeness, and applicability for the intended use. GAO, Assessing Data Reliability Adapt those questions to each evidence object:

• Accuracy: is the object authentic and internally consistent?

• Completeness: does it include every required section, attachment, period, and entity?

• Applicability: does it address this application, site, product, and requirement?

• Currency: is it still valid on the assessment date?

• Authority: did a suitable issuer create or validate it? Never overwrite a certificate, questionnaire, proposal, or test result with a newer version. Mark the prior object superseded, link the replacement, and record why. The old item may explain an earlier stakeholder decision or unresolved discrepancy. Set a confidentiality boundary independently from evidence state. An accepted security response can still be restricted. A public certificate can still be unresolved if it covers the wrong product family. Store only necessary personal and sensitive information, and do not forward buyer documents beyond their permitted audience. For cybersecurity supply-chain evidence, NIST SP 800-161 Rev. 1 provides risk-management practices for systems and organizations. Its scope is cybersecurity supply-chain risk, not general sales. Use it only when that risk domain is materially part of the decision.

5. Record who can evaluate and accept the evidence

For each item, distinguish four functions: 1 Requester: asks for the information. 2 Recipient or coordinator: receives and routes it. 3 Evaluator: judges it against the requirement. 4 Acceptance authority: records satisfaction, exception, or rejection. One person may perform all four functions, but do not assume that. A procurement contact may receive a document while quality evaluates it. A technical evaluator may recommend acceptance while a delegated authority records the decision. If the authority is unknown, the state cannot advance to accepted solely because the sender received no objection. Record acceptance at the requirement level. "Certificate accepted for Product X at Plant A through December 2027" is bounded. "Quality approved us" is not. If an exception exists, record who authorized it, its conditions, covered scope, and expiry. When stakeholders disagree, do not choose the most favorable answer. Keep the competing claims and evidence separate and use BC-26's reconciliation method. The ledger should show the contradiction until a suitable authority resolves it.

6. Calculate ledger coverage without inventing approval

Use several measures, each with its denominator: Provision coverage = provided-or-later applicable items / requested applicable items x 100 Disposition coverage = (accepted + rejected applicable items) / evaluated applicable items x Open evidence exposure = applicable items without an accepted or rejected disposition / applicable items x 100 Define the denominator before calculating. Do not put a merely requested item into the evaluated-items denominator. Do not count superseded copies as additional evidence needs. A high provision rate means the team delivered most requested objects; it does not mean the buyer accepted them. Hard gates remain outside any average. If a mandatory safety certificate is unresolved, ten accepted preferences do not clear it. The register should display gate status beside these coverage measures.

7. Illustrative example

Illustrative example - fictional. A fictional exporter, Northline Pumps, receives six evidence requests for a fictional plant upgrade: Evidence item Current state Evaluated? Gate? Dimensional drawing accepted Yes Yes Material certificate accepted Yes Yes Quality-system certificate provided No Yes Service coverage statement rejected Yes Yes Total-cost worksheet accepted Yes No Cybersecurity statement unresolved Yes No, product connectivity is still being clarified Five of six requested items are at provided or a later state. Provision coverage = 5 / 6 x 100 = 83.3%. Four items have reached a final disposition: three accepted and one rejected. Five items have been evaluated, including the unresolved cybersecurity statement. Disposition coverage = 4 / 5 x 100 = 80%. Two of six applicable items remain without an accepted or rejected disposition, so open evidence exposure = 2 / 6 x 100 = 33.3%. The service coverage statement is a rejected hard gate. Therefore, the bounded decision is Fail pending an accepted alternative or authorized exception, regardless of the other percentages. The team preserves the rejection reason: the submitted statement omitted on-site response in the buyer's region. It does not simply send the same file again. All organizations and numbers are fictional. These calculations describe ledger states, not purchase probability, buyer intent, qualified lead status, or expected revenue.

8. Common mistakes

• Treating an email attachment as accepted evidence.

• Using a filename instead of a stable evidence ID and version.

• Recording the recipient but not the evaluator or authority.

• Marking silence as acceptance.

• Deleting a rejected or superseded object and losing decision history.

• Reusing evidence across sites, products, entities, or periods without verifying scope.

• Combining mandatory gates and preferences into one completion score.

• Counting document volume as evidence quality.

9. What this does not mean

An evidence ledger does not require every purchase to become bureaucratic. Use it for material requirements whose status changes the decision or prevents repeated work. It does not authorize access to confidential buyer information, replace a buyer's portal or formal procurement record, certify regulatory compliance, or guarantee approval. It makes the seller's evidence state transparent and reviewable. This article is not legal, procurement, cybersecurity, quality, or certification advice.

10. Common questions

Is a verbal acceptance valid evidence? It may be relevant, but its authority, scope, wording, date, and applicable process must be clear. For a material gate, obtain the form of confirmation required by the buyer or governing process. Can one document satisfy several requests? Yes. Link the same controlled object to each requirement and record disposition separately. One evaluator may accept it for one purpose while another finds it insufficient for another. What happens when evidence expires? Set an expiry or review trigger. The prior state remains in history, but the current requirement becomes unresolved until suitable current evidence is verified and accepted. Should rejected evidence be removed? No. Retain it according to applicable policy, mark the rejection reason and scope, and link any replacement. The history prevents the same insufficient object from being reused. Does accepted evidence mean the purchase is approved? No. It means the stated requirement was satisfied for the recorded scope. Other requirements, gates, or authorities may remain unresolved.

11. Sources and methodology

This article uses official U.S. and Canadian procurement, quality, cybersecurity, and data-reliability sources. Public procurement examples do not define every private buying process. The lifecycle states, ledger fields, formulas, and disposition rules are SellersGPT editorial tools, not official certification or legal standards. 1 U.S. General Services Administration, Federal Acquisition Regulation Part 9 - Contractor Qualifications. https://www.acquisition.gov/far/part-9. Accessed August 24, 2026. 2 U.S. General Services Administration, Federal Acquisition Regulation Part 15 - Contracting by Negotiation. https://www.acquisition.gov/far/part-15. Accessed August 24, 2026. 3 U.S. General Services Administration, Federal Acquisition Regulation Part 46 - Quality Assurance. https://www.acquisition.gov/far/part-46. Accessed August 24, 2026. 4 National Institute of Standards and Technology, SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final. Accessed August 24, 2026. 5 U.S. Government Accountability Office, Assessing Data Reliability (GAO-20-283G). https://www.gao.gov/products/gao-20-283g. Accessed August 24, 2026. 6 Public Services and Procurement Canada, Checklist for Preparing a Bid. https://canadabuys.canada.ca/en/support/checklist-preparing-bid. Accessed August 24, 2026.