--- title: "Payables (AP)" description: "Payables (AP) — specs for 16 React components: BillForm, BillDetail, BillRegister, DuplicateBillAlert and 12 more." canonical: "https://lopifi.com/docs/catalog/payables" --- # Payables (AP) > Payables (AP) — specs for 16 React components: BillForm, BillDetail, BillRegister, DuplicateBillAlert and 12 more. Source: https://lopifi.com/docs/catalog/payables Part of: Lopifi — Planned: US GAAP books on autopilot, checked by a CPA (https://lopifi.com) --- # Payables (AP) Domain model in [`domain/procure-to-pay.md`](https://lopifi.com/md/docs/domain/procure-to-pay). > **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, because one invoice can legitimately hit 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 AP losses, and one of the most preventable.** 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, since duplicate vendors are how duplicate payments slip past 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). It never passes silently. ## 127. `MatchExceptionQueue` The clerk's worklist, sorted by age then amount. ## 128. `ApprovalChain` Who approves, in what order, what's done and 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 left 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`**, because these payments 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**, with who changed them, when, and what verification was done. 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 are findings. Open POs at period end are commitments, not accruals, and the component keeps them separate. They're disclosed only when they are significant unconditional (noncancelable) purchase obligations (ASC 440).