Skip to content

Last reviewed: 2026-07-29 Accepted decisions: - ../decisions/accepted/0024-operational-summary-workflow-boundaries-and-purchasing-facts.md - ../decisions/accepted/0028-standard-cost-inventory-period-summaries.md - ../decisions/accepted/0029-cross-workflow-accounting-event-identity.md

Purchasing and Payables Summary Fact Contract

Canonical object: PurchasingAndPayablesSummaryFact

Canonical child concept:

  • PurchaseAccountingComponent
  • PurchaseControlEvidence
  • VendorPaymentAllocation
  • GrniSettlementAllocation
  • PrepaymentRecognitionAllocation

Allowed fact types:

  • purchasing_payable_summary
  • purchasing_direct_purchase_summary
  • purchasing_vendor_payment_summary
  • purchasing_prepayment_recognition_summary
  • purchasing_accrual_summary

Required concepts:

  • company id
  • actor id
  • owning summary workflow
  • fact type and source event stage
  • source system
  • source object and external event identity
  • idempotency key
  • source document id
  • source-world activity date or date range
  • posting date or target financial period when known
  • currency
  • external reference
  • change type
  • evidence references
  • posting-template version
  • mapping version
  • validation issues
  • resulting summary-batch and journal-entry references when accepted and posted

Accepted source event stages:

Fact type Required source event stage
purchasing_payable_summary vendor_invoice_accepted
purchasing_direct_purchase_summary direct_purchase_completed
purchasing_vendor_payment_summary vendor_payment_issued
purchasing_prepayment_recognition_summary prepayment_recognized
purchasing_accrual_summary accrual_recognized

Other fact and stage combinations remain unsupported until their governing slice accepts a stable stage.

Conditional concepts:

  • vendor or payee external reference and display name
  • vendor invoice identifier
  • purchase-order and receipt identifiers
  • one or more purchase components
  • reviewed acquisition policy: invoice_led
  • payment channel key and policy version when settlement is present
  • reviewed settlement mode: direct_bank, direct_cash, or disbursement_clearing
  • selected funding or clearing account id when applicable
  • payable, direct-purchase, payment, prepayment-recognition, or accrual amount
  • one or more prepayment-recognition allocations when recognition is present
  • related GRNI accrual reference for a later vendor invoice
  • adjusted GRNI carrying amount and invoice-settlement allocation
  • related Inventory-owned PPV event reference when PPV adjusted linked GRNI
  • one or more vendor payment allocations
  • PurchaseControlEvidence
  • related accepted-event references when applicable, within or across workflows
  • preserved external accounting lines and reconciliation totals when supplied

PurchaseAccountingComponent contains:

  • disposition: operating_expense, inventory_acquisition, or prepaid_expense
  • reviewed BooksPlus account id
  • amount
  • capital classification: not_capitalizable, potentially_capitalizable, or identified_capitalizable
  • capital-classification evidence or reviewed mapping reference
  • optional source classification or description preserved as evidence
  • stable component reference when disposition is prepaid_expense

PurchaseControlEvidence may contain:

  • purchase-order, receipt, vendor-invoice, payment, and allocation identifiers
  • invoice, accounting, due, receipt, payment-approval, payment-issue, and clearing dates
  • match type: two_way, three_way, not_applicable, or unknown
  • match status, tolerance result, hold status, exception references, approval actor, and approval time
  • gross, tax, freight, discount, landed-cost, net, and source control totals
  • source currency and exchange-rate evidence
  • source dimensions and reviewed account-mapping references
  • supporting Source Document references

VendorPaymentAllocation contains:

  • vendor invoice external identity
  • allocated amount
  • optional discount, adjustment, or withholding evidence

GrniSettlementAllocation contains:

  • related accepted GRNI accrual event reference
  • posted GRNI carrying amount allocated from that accrual
  • invoice inventory-acquisition amount allocated to that accrual
  • adjusted GRNI carrying amount allocated for settlement
  • currency
  • related accepted Inventory PPV event reference when variance is nonzero
  • relationship and reconciliation evidence references

PrepaymentRecognitionAllocation contains:

  • related accepted and posted prepayment-acquisition event reference
  • stable prepaid-expense component reference within that event
  • original posted prepaid-component amount
  • reviewed operating-expense account id
  • recognized amount
  • company currency
  • recognizes_prepayment relationship reference
  • relationship and reconciliation evidence references

Role requirements:

Fact or component Required roles and selections
operating-expense component reviewed account assigned repeatable expense.operating
inventory-acquisition component inventory.general or another role later accepted by Inventory Summary truth
prepaid-expense component singleton asset.prepaid_expenses
purchasing_payable_summary component roles plus payable.trade; or linked liability.goods_received_not_invoiced and payable.trade when settling an adjusted GRNI accrual
purchasing_direct_purchase_summary component roles plus selected bank.operating, cash.on_hand, or clearing.payment_disbursements, as permitted by source ownership and settlement mode
purchasing_vendor_payment_summary payable.trade plus selected bank.operating or clearing.payment_disbursements
purchasing_prepayment_recognition_summary repeatable expense.operating plus singleton asset.prepaid_expenses
operating-cost purchasing_accrual_summary repeatable expense.operating plus liability.accrued_expenses
uninvoiced-inventory purchasing_accrual_summary inventory.general plus liability.goods_received_not_invoiced

Rules:

  • Facts are provider-agnostic summaries, not operational purchase orders, receipt records, vendor invoices, payable subledger records, payment instructions, vendor-master records, or bank-reconciliation records.
  • The ordinary acquisition policy is invoice-led. Purchase-order approval and receipt acceptance are non-posting control events.
  • One purchasing_accrual_summary classifies wholly as an uninvoiced operating cost or wholly as uninvoiced inventory; it does not mix the two liability templates in one fact.
  • An uninvoiced-inventory accrual retains the reviewed invoice_led policy. It is the explicit period-end accrual accepted by ADR 0024, not a general receipt-led acquisition policy.
  • A valid payable does not depend on match completion, removal of a payment hold, OK-to-pay approval, or payment authorization.
  • Match, hold, OK-to-pay, payment-proposal, and bank-clearing states are preserved control evidence and do not themselves request posting.
  • Every normalized source accounting event has exactly one owning Summary workflow and at most one ordinary posting result.
  • Cross-workflow links preserve source relationships and navigation but do not authorize posting.
  • Separate receipt, payment, deposit, disbursement, and settlement stages require separate source event identity.
  • Invoice-led and receipt-led acquisition posting must not both recognize the same goods.
  • Inventory may provide quantity and valuation evidence to a Purchasing fact and may later post consumption, valuation, or variance events, but it does not repost the Purchasing-owned acquisition.
  • A related invoice reference on a Finance payment explains the payment; it does not create or reroute an invoice fact.
  • Every fact references an active, same-company Source Document.
  • Vendor and payee references provide traceability without creating a BooksPlus operational vendor master or payable subledger.
  • Components use reviewed BooksPlus account ids. Provider journal codes, account codes, descriptions, product names, or vendor names do not select their disposition or target account.
  • Component amounts are positive and sum exactly to the applicable fact amount.
  • Inventory Summary is the sole owner of PPV events and posting lines. Purchasing may preserve PPV evidence and the related Inventory event reference, but a Purchasing template never selects expense.purchase_price_variance.
  • An invoice that settles an existing GRNI accrual debits the linked adjusted liability.goods_received_not_invoiced carrying amount and must not also debit inventory acquisition or PPV for the same goods.
  • When PPV is required to reconcile invoice inventory-acquisition value to posted GRNI, the Inventory-owned PPV event must adjust that GRNI balance before the Purchasing invoice becomes ready to settle it.
  • A nonzero GRNI variance requires resolved supports_purchase_price_variance, adjusts_accrual, and settles_accrual relationships in the directions accepted by ADR 0029.
  • Zero variance preserves the reconciliation and settles_accrual relationship but creates no zero-value PPV event or adjusts_accrual relationship.
  • Partial or many-to-many GRNI settlements use explicit GrniSettlementAllocation children. Their amounts must not overlap or exceed the adjusted open GRNI balance.
  • A prepaid-expense component on a payable or direct-purchase fact acquires a non-inventory prepayment in asset.prepaid_expenses. Its stable component reference is unique within the owning event and does not derive from provider account codes, descriptions, or line position alone.
  • purchasing_prepayment_recognition_summary is a distinct original event at prepayment_recognized. It debits reviewed expense.operating components and credits asset.prepaid_expenses; it does not create a payable, settle a payment, acquire another prepayment, or affect inventory or GRNI.
  • Every prepayment-recognition allocation resolves a posted same-company payable or direct-purchase event and one of its prepaid-expense components. The reviewed expense account in the allocation matches an operating-expense component on the recognition fact.
  • recognizes_prepayment points from the recognition event to its acquisition. Its company-currency amount equals the recognition allocations for that acquisition endpoint.
  • Partial and many-to-many prepayment recognition is allowed. Allocation amounts are positive and may not overlap or exceed the acquisition component's available balance.
  • Posted open balance equals the posted prepaid-component amount less posted recognition allocations. ready_to_post recognition allocations reserve available balance; staged, held, and abandoned batches do not. Readiness and posting enforce the balance atomically.
  • Recognition is manual and evidence-backed. Automatic amortization schedules, inferred service periods, generated periodic allocations, and recurring recognition events are not accepted.
  • One vendor payment may allocate to several invoices. Allocation amounts sum exactly to the payment amount.
  • Every ordinary vendor-payment fact contains at least one allocation. An unallocated or unapplied vendor payment remains held until separately accepted truth defines its treatment.
  • direct_cash is supported only for a direct-purchase fact.
  • direct_bank and disbursement_clearing are mutually exclusive settlement modes for one vendor payment event.
  • A direct-bank payment credits the selected bank.operating account. Its later bank-statement match is non-posting reconciliation state.
  • A disbursement-clearing payment credits the selected clearing.payment_disbursements account. A later Finance-source settlement is a separate event that clears it to the bank.
  • Fees, interest, exchange differences, and statement discrepancies are separate Banking and Finance events.
  • One prepared journal entry uses one explicit currency.
  • Preserved external accounting lines are reconciliation evidence, not posting instructions.
  • Each summarized posting reconciles to a reviewed operational control total and preserves or references the invoice, receipt, match, approval, and allocation evidence needed to explain that total.
  • Purchasing and Inventory effects reconcile without duplicating a source accounting event.
  • A direct purchase already settled to bank, cash, or card in one Finance-owned event routes to Banking and Finance Summary and does not also create a Purchasing posting.
  • An identified or potentially capitalizable purchase remains held for a later fixed-asset workflow and must not be silently reclassified.
  • Every component on a core purchase-bearing fact has an explicit capital classification. A missing, potentially_capitalizable, or identified_capitalizable classification blocks preparation of the entire fact. Only not_capitalizable may proceed through the core templates.
  • Contractor classification, W-9 and taxpayer-identification evidence, sensitive-data handling, and 1099 reporting remain assigned to Slice 0B.
  • BillCatcher and the entire capital-project and fixed-asset lifecycle are deferred beyond the initial release.
  • Use tax, vendor tax treatment, payroll, automatic amortization, accounting cost allocations, recurring entries, and correction meaning are outside this contract. Explicit workflow-owned prepayment-recognition allocations are not automatic accounting cost allocations.
  • Prepared previews remain Summary Accounting review state.
  • Posting uses protected Summary actions and central Accounting posting.

Validation expectations:

  • fact type and source event stage are explicit and supported;
  • owning workflow, company, actor, source identity, Source Document, activity date, posting date or target period, currency, external reference, and idempotency key are present where required by the intake path;
  • Source Document, selected accounts, import candidate, Summary batch, and related-event references are company-scoped;
  • each posting source event resolves to one owning workflow and no prior ordinary posting result;
  • every purchase-bearing fact has at least one component unless a payable fact exclusively settles a linked GRNI accrual;
  • selected component accounts match their roles;
  • ordinary inventory acquisition declares invoice-led policy;
  • every prepaid-expense acquisition component has a stable reference unique within its owning Purchasing event;
  • a linked GRNI settlement resolves the prior accrual, uses its adjusted carrying amount, and excludes duplicate inventory-acquisition and PPV debits;
  • any required PPV-to-GRNI adjustment is an accepted, posted Inventory event with a resolved same-company relationship before invoice settlement;
  • GRNI accrual, Inventory PPV, and invoice-settlement allocations reconcile exactly in the company currency;
  • a GRNI-settling payable total equals its GrniSettlementAllocation total, and each allocation equals the adjusted open carrying amount it settles;
  • prepayment recognition uses only the accepted fact and stage combination, contains at least one allocation, and contains only operating-expense components;
  • each recognition allocation resolves a posted original same-company payable or direct-purchase prepaid component and a resolved recognizes_prepayment relationship in the accepted direction;
  • recognition allocations sum exactly to the fact amount and to operating- expense components, prepared debits and credits, and the reviewed operational control total;
  • allocations grouped by acquisition endpoint equal that relationship amount, use company currency, and do not exceed posted open balance after active ready reservations;
  • prepayment recognition contains no settlement mode, selected settlement account, payment-channel policy, vendor-payment allocation, GRNI settlement, or prepaid-acquisition component;
  • a direct purchase uses exactly one supported settlement mode: direct_bank, direct_cash, or disbursement_clearing;
  • a vendor payment uses exactly one supported settlement mode: direct_bank or disbursement_clearing;
  • a payable-recognition fact has no settlement mode or selected settlement account;
  • settlement mode and selected funding or clearing account agree;
  • payment channel and policy version support the selected settlement mode;
  • every vendor payment has at least one allocation and allocations sum exactly to the payment total;
  • match and approval states cannot create posting requests;
  • component, fact, external-line, and prepared-entry totals reconcile;
  • prepared totals reconcile to the reviewed operational control total;
  • prepared debits equal prepared credits;
  • related references do not create additional posting requests;
  • potential capital classification produces a blocking issue; and
  • unresolved error issues prevent ready-to-post status.

Related binding contracts:

  • account-role.contract.md
  • accounting-import-candidate.contract.md
  • inventory-period-summary-fact.contract.md
  • summary-accounting-batch.contract.md
  • source-document.contract.md
  • journal-entry.contract.md
  • money.contract.md