# Payables (AP)

> Payables (AP) — specs for 16 React components: BillForm, BillDetail, BillRegister, DuplicateBillAlert and 12 more.

Source: https://lopifi.com/docs/catalog/11-payables
Part of: Lopifi — US GAAP books on autopilot, reviewed by a CPA (https://lopifi.com)

---

# Payables (AP)

Domain model in [`domain/06-procure-to-pay.md`](../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.