# Procure-to-Pay Protocol — Workflow and Output Contract

## Overview
This document provides the detailed step-by-step workflow, decision tree, and output contract for the procure-to-pay-protocol skill. It covers the full source-to-pay cycle from purchase requisition through vendor payment settlement, with explicit SoD gate definitions.

---

## Detailed Step-by-Step Workflow

### Phase 1 — Requisition and Budget Check (d365-supply-chain-plan-to-produce-agent)

**Step 1.1 — Receive and validate purchase requisition**
- Confirm the purchase requisition is submitted by an authorized requester in Dynamics 365 Supply Chain Management.
- Validate that the requested goods or services are within the approved procurement catalog.
- Check that procurement policies (spending limits, preferred vendor requirements) are met.
- If the request is outside the catalog or policy, reject and return to the requester with an explanation.

**Step 1.2 — Budget availability check**
- Query available budget for the relevant cost center and account in Dynamics 365 Finance.
- If budget is insufficient, pause immediately and escalate to the finance owner for budget approval.
- Do not convert a requisition to a PO without a confirmed budget check pass.

**Step 1.3 — Vendor selection and pricing validation**
- Confirm vendor account, trade agreement pricing, and delivery terms in Dynamics 365 Supply Chain Management.
- For new vendors, flag for vendor master review before PO creation — do not create a PO for an unvalidated vendor.

---

### Phase 2 — Purchase Order Approval and SoD Gate (d365-supply-chain-plan-to-produce-agent + d365-security-sod-governance-agent)

**Step 2.1 — Convert requisition to purchase order**
- Create the purchase order in Dynamics 365 Supply Chain Management with all line items, quantities, prices, and delivery dates.
- Assign the PO to the configured approval workflow.

**Step 2.2 — SoD gate: PO approval review**
- Invoke d365-security-sod-governance-agent to verify:
  - The PO approver is not the same person who created the purchase requisition.
  - The PO approver is not the designated goods receiver for this PO.
  - No single person can complete all three roles: requisition, approval, and receipt.
- If any SoD conflict is detected, halt the approval immediately; escalate to the compliance owner and document the conflict with evidence.
- Do not proceed with PO approval until the SoD conflict is resolved by the compliance owner.

**Step 2.3 — PO confirmation and vendor communication**
- Once approved and SoD-cleared, confirm the purchase order.
- Send the confirmed PO to the vendor; record the vendor's acknowledgment reference.
- Set the expected delivery date in the system.

---

### Phase 3 — Goods/Services Receipt (d365-supply-chain-plan-to-produce-agent)

**Step 3.1 — Delivery monitoring**
- Track delivery against the promised date on the PO.
- Flag overdue deliveries to the supply chain agent and human owner.

**Step 3.2 — Goods receipt or service entry sheet**
- Upon delivery, record the goods receipt note (GRN) or service entry sheet in Dynamics 365 Supply Chain Management.
- Perform quantity check: received quantity must match or be documented against PO quantity.
- Perform quality check (where applicable) and record any discrepancies.
- The goods receiver must be a different person than the PO requisitioner and approver (SoD).

---

### Phase 4 — Vendor Invoice Processing (d365-finance-close-to-report-agent)

**Step 4.1 — Invoice receipt and capture**
- Receive vendor invoice in Dynamics 365 Finance (manual entry, OCR via Azure AI Document Intelligence, or EDI).
- Match invoice header to the correct vendor account and PO reference.

**Step 4.2 — Three-way match**
- Perform three-way match: purchase order line quantities and prices, goods receipt quantities, and vendor invoice quantities and amounts.
- If the match passes within configured tolerances, route for payment approval.
- If the match fails (price discrepancy, quantity mismatch, or missing receipt), hold the invoice; route to d365-supply-chain-plan-to-produce-agent and the vendor for resolution.
- Document all match exceptions with reason codes.

**Step 4.3 — Invoice approval and payment queue**
- Approved and matched invoices are queued for payment in Dynamics 365 Finance per the vendor's payment terms.
- Invoices above the configured materiality threshold require a second human approval before payment is included in the payment run.

---

### Phase 5 — Payment Settlement (d365-finance-close-to-report-agent + human)

**Step 5.1 — Payment authorization**
- The payment run proposal is generated by d365-finance-close-to-report-agent and presented to the authorized finance signatory.
- No payment is released without explicit human authorization of the payment run.
- SoD check: the person authorizing the payment run must not be the same person who approved the invoice.

**Step 5.2 — Payment execution and settlement**
- Human-authorized payment run is executed in Dynamics 365 Finance.
- Payment is applied to the vendor's open transactions; accounts payable entries are settled.
- Payment confirmation and remittance advice are sent to the vendor.

---

## Decision Tree

```
START: Purchase requisition received
│
├─ Request within procurement catalog and policy?
│   └─ NO → REJECT; return to requester
│
├─ Budget available?
│   └─ NO → PAUSE; escalate to finance owner
│
├─ Vendor validated in vendor master?
│   └─ NO → FLAG for vendor master review; do not create PO
│
├─ SoD: Approver ≠ Requisitioner ≠ Receiver?
│   └─ NO → HALT; escalate to d365-security-sod-governance-agent and compliance owner
│
├─ Vendor acknowledged PO?
│   └─ NO → MONITOR; escalate on overdue acknowledgment
│
├─ Delivery received and GRN created?
│   └─ NO → MONITOR; flag overdue delivery
│
├─ Three-way match passes?
│   └─ NO → HOLD invoice; route to supply chain and vendor
│
├─ Invoice above materiality threshold?
│   └─ YES → REQUIRE second human approval
│
├─ Payment run authorized by finance signatory?
│   └─ NO → DO NOT release payment
│
└─ SoD on payment: Authorizer ≠ Invoice approver?
    └─ NO → HALT; escalate to compliance owner
```

---

## Output Contract

Every execution of this protocol produces a structured output capsule:

| Field | Type | Description |
|---|---|---|
| matter_id | string | Unique identifier for this P2P instance |
| po_id | string | Purchase order number |
| current_stage | enum | One of: requisition, budget_check, po_approval, sod_check, goods_receipt, invoice_matching, payment_queue, settled |
| gate_outcomes | object | Pass/fail/escalated: budget, policy, sod_po, three_way_match, sod_payment, payment_auth |
| agents_involved | array | Agent IDs that participated |
| escalations | array | Each escalation: {trigger, timestamp, escalated_to, reason} |
| open_questions | array | Unresolved items requiring human input |
| do_not_do_list | array | Actions explicitly prohibited in the current state |
| evidence_quality | enum | high / medium / low |
| privilege_sensitivity | boolean | True if commercially sensitive vendor terms are involved |
| last_updated | ISO8601 timestamp | When the capsule was last updated |

---

## Audit Log Fields
- matter_id, skill_id, skill_version, invoked_by, input_hash, evidence_quality, output_verdict, escalation_fired, sod_conflict_detected, timestamp