AI Vendor Onboarding Agent: Due-Diligence Packet and Cost Worksheet

Jump to the cost worksheet if the workflow is already scoped. This resource is for a procurement operations, security or finance leader choosing one supplier-creation lane. It is an internal reference model with synthetic arithmetic, not a client result, legal opinion, tax instruction or vendor recommendation.

Choose the record that ends the workflow

The pilot succeeds when an approved vendor record exists in the system of record and matches the reviewed packet. A submitted form, an agent run or an accepted API receipt is not the outcome.

Start with one vendor class and one destination. A useful first lane might be new US software suppliers entering one ERP. Name the business owner, required evidence, approval matrix, duplicate rule and final system before adding an agent. If regional entities, contingent workers, physical-goods suppliers and payment changes use different rules, keep them out of the first cohort.

Use this contract:

• Intake: one request channel with requester identity, legal supplier name, service scope and business owner.
• Evidence: one versioned policy that states what company, security, tax and banking evidence this vendor class needs.
• Decision: named procurement, security and finance owners approve only the issues they own.
• Write: one narrowly scoped tool can prepare or create the vendor record after the approvals are present.
• Acceptance: the system of record reads back the intended identity, status and control fields.
• Stop: a risk concern, rejection, confirmed duplicate, failed independent verification or contradictory read-back blocks progression.

That is an agent workflow operating contract, not a prompt. The agent may extract and normalize documents. It may not invent the missing approval policy or inherit the operator's authority.

Build one inspectable vendor packet

Normalize the evidence before routing it. An inbox full of attachments is not an auditable packet, and a prose summary cannot show which field came from which source.

For an information and communications technology supplier, NIST's July 2026 Due Diligence Assessment Quick-Start Guide supplies a useful research spine. It defines five categories: foreign ownership, control or influence; provenance; resilience; foundational cyber practices; and supply chain tiers. The guide says organizations should choose the diligence level based on acquisition criticality and available resources, then validate findings against multiple sources when possible.

SP 1326 is scoped to ICT suppliers and supplements NIST SP 800-161 Rev. 1. Do not turn its five categories into universal approval law. Use them as explicit fields when the supplier is in scope, and keep your organization's legal, finance and procurement requirements in their own versioned policy.

The minimum packet looks like this:

{
  "request_id": "req-042",
  "requester_id": "buyer-17",
  "supplier": {
    "legal_name": "Example Supplier LLC",
    "service_scope": "Hosted incident paging service",
    "company_identity_verified": true
  },
  "business_owner": "operations-owner",
  "due_diligence": [
    { "category": "provenance", "status": "clear", "sources": ["src-12", "src-19"] },
    { "category": "resilience", "status": "pending", "sources": [] }
  ],
  "tax_evidence": { "status": "complete", "policy": "us-vendor-v4" },
  "bank_instructions": { "status": "independently_verified", "evidence": "call-77" },
  "duplicate_check": { "status": "clear", "candidates": [] },
  "approvals": {
    "procurement": "approved",
    "security": "pending",
    "finance": "approved"
  },
  "policy_version": "vendor-onboarding-v7",
  "route": "collect_evidence"
}

Every extracted claim needs its source identifier and collection time. Every approval needs an accountable human identity, policy version and decision time. Sensitive source documents stay in the system authorized to hold them; the agent packet carries references and normalized fields, not an unnecessary second archive.

For US tax evidence, the IRS says Form W-9 supplies a correct taxpayer identification number to a person required to file an information return. That does not mean every supplier or entity belongs on the same tax route. Your finance and tax policy decides which evidence applies. The agent reports complete, pending or not_required against that policy.

Give every packet an observable terminal

Use distinct terminals for missing evidence, human decisions, risk stops and system outcomes. A single confidence score cannot express who still owes a decision or whether the authoritative write actually landed.

1. Collect evidence: required identity, diligence, tax or independent banking evidence is missing.
2. Human review: evidence is present, but a possible duplicate or pending approval needs an accountable owner.
3. Hold risk: a diligence concern, confirmed duplicate, rejected approval or failed verification blocks creation.
4. Ready to create: every required field and approval is present, but no write has been accepted.
5. Uncertain: the write returned a receipt, but the authoritative record cannot be read back.
6. Divergent: authoritative read-back contradicts the approved intent.
7. Reconciled: the authoritative vendor record matches the approved packet.

The two post-write failure states deserve their own queues. Uncertain means the agent does not know whether retrying would create a duplicate. Divergent means the system says something different from the approved packet. Neither state permits blind replay. Use the receipt and outcome verification method to reconcile before another write.

Do not convert every concern into rejection. A concern is a finding that needs the designated owner and the organization's risk policy. The agent should preserve the evidence, route and decision. It should not convert its own risk score into corporate approval.

Price the reconciled vendor

Join technology, setup and human work for the same period, then divide by reconciled vendors. Requests received, forms parsed and packets drafted are activity counts, not completed vendor onboarding.

Use:

joined monthly cost = platform/runtime + integration/operations + amortized setup + procurement review + security exceptions + rework

Then:

cost per reconciled vendor = joined monthly cost / authoritative vendor records that match approved packets

Blank worksheet

Synthetic arithmetic check

This fixture tests the worksheet. It is not a vendor price, industry benchmark, client result or savings forecast.

• 80 requests in one month
• $250 platform/runtime and $350 integration/operations
• $9,600 setup amortized over 12 months, or $800 for the month
• 12 procurement-review hours, 8 security-exception hours and 4 rework hours
• $90 synthetic loaded hourly cost
• 64 reconciled vendors

Recurring technology cost is $600. Modelled human cost is 24 hours multiplied by $90, or $2,160. Joined monthly cost is $3,560. Dividing by 64 reconciled vendors produces a synthetic unit cost of $55.63.

Add every cost your workflow actually incurs. Common omissions include supplier-data subscriptions, identity or sanctions services, ERP licensing, independent banking verification, tax validation, document storage, security remediation and incident handling. If no vendor reaches reconciliation, unit cost is unavailable. Report that directly instead of dividing by requests.

Run the packet evaluator

The dependency-free reference below demonstrates the route contract. It does not investigate a real supplier, validate a tax form, check sanctions or approve risk. It evaluates an already normalized packet.

export function routeVendorPacket(packet) {
  const required = ["requestId", "requesterId", "supplierLegalName", "serviceScope", "businessOwner"];
  if (required.some((key) => !packet[key]) || !packet.traceableCompanyVerified) {
    return { route: "collect_evidence" };
  }

  if (packet.dueDiligenceChecks.some((item) => item.status === "pending")) {
    return { route: "collect_evidence" };
  }

  if (
    packet.dueDiligenceChecks.some((item) => item.status === "concern") ||
    packet.duplicateStatus === "confirmed" ||
    packet.bankInstructionStatus === "failed" ||
    Object.values(packet.approvals).includes("rejected")
  ) {
    return { route: "hold_risk" };
  }

  if (
    packet.duplicateStatus === "possible" ||
    Object.values(packet.approvals).includes("pending")
  ) {
    return { route: "human_review" };
  }

  if (!packet.createReceipt) return { route: "ready_to_create" };
  if (!packet.observedVendor) return { route: "uncertain" };

  return JSON.stringify(packet.createReceipt.intendedVendor) === JSON.stringify(packet.observedVendor)
    ? { route: "reconciled" }
    : { route: "divergent" };
}

The retained full model adds input validation, tax and banking evidence states, joined economics and an eight-control release gate. Twenty local synthetic cases pass. They cover arithmetic, an empty denominator, missing identity, pending and concerning diligence findings, possible and confirmed duplicates, pending and failed banking verification, pending and rejected approvals, create readiness, unavailable read-back, divergent read-back and reconciliation.

Those are contract checks, not accuracy or performance results. A production test set must use representative de-identified packets and expected routes approved by the people who own the workflow.

Release one bounded vendor class

The first production release should prove the control plane before it expands supplier coverage.

1. Name one vendor class, request channel and authoritative vendor system.
2. Version the required fields, due-diligence policy and approval matrix.
3. Identify authoritative sources for company identity and each diligence field.
4. Keep tax evidence conditional on the organization's policy and entity context.
5. Separate banking-instruction collection from independent verification.
6. Test exact and fuzzy duplicate candidates before creating a vendor.
7. Restrict the create tool to approved fields and the chosen vendor class.
8. Seed negative cases: missing identity, conflicting sources, risk concern, possible duplicate, approval rejection and failed verification.
9. Require human acceptance for every policy exception and risk decision.
10. Store the approved intent with the create request and receipt.
11. Read the authoritative vendor record back and compare control fields.
12. Stop automatic retries for uncertain or divergent outcomes.
13. Review every route and exception with the workflow owner during the pilot.
14. Expand only after the negative cases and reconciliation gate hold for the first class.

The release gate has eight yes-or-no controls: named request scope, named authoritative sources, versioned diligence policy, versioned approval matrix, configured duplicate check, separated banking verification, restricted create authority and authoritative read-back. If one is missing, the pilot is not ready for a production write.

Record evidence without building a second data swamp

Log the decision path, not every sensitive document again. Keep source material where policy permits it and retain the identifiers needed to reconstruct the route.

For each packet, record:

• request, requester, supplier and business-owner identifiers;
• policy and approval-matrix versions;
• each normalized field, source identifier and collection time;
• diligence category, status and accountable owner;
• duplicate candidates and resolution;
• independent verification reference without exposing secret banking data;
• approval identity, decision and time;
• intended create payload hash, tool receipt and retry key;
• authoritative record identifier, observed fields and reconciliation status;
• exception, incident and final terminal.

NIST SP 800-53 Rev. 5 provides a customizable catalog of audit, access-control, separation-of-duties and least-privilege controls. Use the organization's selected controls and policy rather than claiming that this worksheet establishes compliance.

The evidence record should let an operator answer three questions: what did the agent believe, who approved the decision and what did the authoritative system finally contain? If the log cannot reconstruct those answers, it cannot support a safe replay or an incident review.

Keep these decisions outside the agent

The bounded workflow prepares an evidence-complete request and performs an authorized write. It does not own the business decision.

Keep these outside:

• accepting a due-diligence concern or residual supplier risk;
• choosing which suppliers are critical or which diligence tier applies;
• interpreting tax status or legal entity requirements;
• verifying bank instructions through the same channel that supplied them;
• approving payment, releasing funds or changing existing payment details;
• waiving a required security, procurement or finance approval;
• resolving a confirmed duplicate by overwriting an existing record;
• treating an API receipt as authoritative completion;
• retrying an uncertain create without reconciliation.

This boundary leaves useful work for the agent: document classification, field extraction, source binding, missing-evidence requests, duplicate candidates, approval routing, packet assembly, create preparation and read-back comparison. Those steps can reduce coordination work without hiding who owns supplier risk and payment authority.

Frequently asked questions