Payables (AP)
Domain model in domain/06-procure-to-pay.md.
Every AP screen is a control surface. Approval, segregation of duties, and duplicate detection are the reason these forms exist.
122. BillForm
Per-line account and full dimensions — a single invoice legitimately hits four departments. Default coding suggested from this vendor's history, shown as a suggestion with its basis. Source document attachment is required; a bill without one cannot be approved.
Early-payment discounts surface as a decision with the annualized return: "Pay by 12 Oct to save $240 (2%) — a 37% annualized return."
123. BillDetail
The source document rendered inline beside the coding, match, approval chain, and audit trail. An approver who has to click through to see what they're approving will stop clicking through.
124. BillRegister
All bills with aging and approval state, filterable.
125. DuplicateBillAlert
Duplicate payment is one of the most common — and most preventable — AP losses.
Runs before save. Primary key: vendor + vendorInvoiceNumber. Secondary fuzzy check: vendor + amount + date ± 5 days. Blocking, showing the suspected duplicate side by side with the new entry. Also detects duplicate vendors by name similarity and tax ID — duplicate vendors are how duplicate payments survive duplicate-invoice checks.
126. ThreeWayMatch
PO, goods receipt, and invoice side by side, line by line, with differences highlighted at the line level. A header total that matches while lines don't is how overbilling hides. Tolerances displayed. A variance requires a disposition — accept with reason, request a vendor credit, partial-pay, or reject — never a silent pass.
127. MatchExceptionQueue
The clerk's worklist, sorted by age then amount.
128. ApprovalChain
Who, in what order, what's done, what's blocking — visible before submission. Threshold escalation shown while the amount is being typed, not after submitting. Segregation of duties is enforced, not advisory: for the preparer, the approve action is absent, not disabled.
Approvals bind to a version. Editing an approved bill voids the approvals and re-requests them, with the change shown to the re-approver. This closes the classic post-approval-edit fraud path.
129. ApprovalInbox
Mobile-first. Approvals happen on phones between meetings, so the source document must be readable at 390px. Swipe actions with an explicit button equivalent. Rejection requires a reason and routes back to the preparer with it visible.
130. PaymentRunBuilder
Select bills by due date, vendor, or discount deadline. Shows the run total and, most importantly, the cash balance remaining after the run — a payment run that overdraws is a very expensive UI failure.
131. PaymentRunPreview
Final confirmation: vendor, amount, method, bank details, arrival estimate, resulting cash. HoldToConfirm — these are irreversible and often large. Partial failure is a first-class state showing exactly which payments failed and what to do.
132. CashRequirements
Due in 7 / 14 / 30 days against available cash, with payroll as a separate prominent line. The view AP managers actually plan from.
133. VendorMaster
Bank details are versioned, never overwritten — who changed them, when, and what verification was performed. Vendor onboarding is itself an approval, separate from bill entry. Flags missing W-9s before year-end. Shows sanctions/OFAC screening status where the integration exists.
134. BankDetailChangeAlert
The fraud-prevention surface. Vendor-impersonation attacks work by changing bank details before a large payment, and the UI is the last line of defense.
A bank detail change within N days of a scheduled payment is flagged, requires out-of-band re-verification, and appears prominently in the payment run preview with the old and new details side by side and the change's actor and timestamp.
135. ExpenseCapture
Camera-first, mobile. OCR pre-fills amount, date, and merchant as editable suggestions shown next to the image. Policy violations appear at entry, not at approval, so the fix is cheap. Personal / reimbursable / corporate-card-paid are three distinct settlement paths and the UI never guesses.
136. CardTransactionMatch
Corporate card transactions matched to receipts, not re-entered. Unmatched-receipt and unmatched-transaction queues are both first-class.
137. UninvoicedReceiptsReport
GR/IR aging: goods received not yet invoiced. This report is the evidence for the period-end accrual entry, and it generates it. Old balances mean a missing invoice or a receipt that never happened — both findings. Open POs at period end are commitments, not accruals — disclosed only when they are significant unconditional (noncancelable) purchase obligations (ASC 440) — and the component keeps them separate.