Accounts Payable Timing Governance
Accounts Payable often pays invoices according to check-run timing rather than actual due dates. When that happens, cash leaves the business earlier than necessary for no real benefit. This framework documents a basic control logic: release only what is due within the next 3 business days unless a documented exception justifies early payment. The objective is to preserve working capital, reduce avoidable borrowing, and impose payables timing discipline without adding software, headcount, or unnecessary process.
Scope / Trigger
This framework applies when invoices are routinely paid before due date because Accounts Payable follows payment-run habit rather than due-date discipline. If bills are released when they enter the queue instead of when they are actually due, and no one tracks how many days early payments go out, this framework applies.
Typical trigger conditions:
- Accounts Payable runs occur weekly or bi-weekly.
- Invoices are paid when processed rather than when due.
- Payment approval and payment release occur at the same moment.
- The organization does not track average days early paid.
A useful diagnostic threshold: if average payment timing lands 5 or more days before due date, this framework is relevant.
Failure Mode
Cash leaves the company because the payment run arrived — not because the invoice was due.
Accounts Payable is being handled as a task-completion process instead of a cash-timing discipline. Bills are approved and released at the next payment run regardless of actual due date. Invoices enter the queue days or weeks before maturity, and cash leaves the operating account before it has to. The business then absorbs lower liquidity or replaces that avoidable gap with borrowing.
Paying early is not neutral. It is equivalent to giving vendors a short-term, interest-free loan using your own working capital.
Control Rule + Owner
At each payment run, release only invoices due within the next 3 business days. Early payment is an exception, not normal Accounts Payable behavior.
Owner:
The person who executes payment runs.
Allowed exceptions:
- Early-pay discount where annualized return exceeds cost of capital.
Quick test:(Discount % / (1 – Discount %)) × (365 / Days early)
A 2/10 net 30 discount annualizes to approximately 36% and is usually worth taking. - Credible vendor hold or supply disruption risk, documented by email or payment note.
- Owner or management override for vendor relationship reasons, logged with a stated reason.
Documentation threshold:
Any invoice above $10,000 paid outside the 3-business-day window must be logged with the reason. One line is sufficient. Email approval counts.
Minimum Viable Implementation
- Pull the last 90 days of paid invoices.
- Calculate average days early paid.
- Test whether the bank debits ACH payments on approval date or execution date.
- Set one or two fixed payment runs per week.
- At each run, release only invoices due within the next 3 business days.
- Log every early-payment exception.
- Review average days early paid monthly.
Important: platform testing is mandatory. Some banking platforms, including certain Bank of America CashPro ACH configurations, remove cash from the account immediately when payment is approved, even if a future execution date is selected. In that environment, future-dated ACH does not preserve float.
If scheduled ACH debits immediately and the vendor accepts checks, FF-AP-002 may provide an alternative timing mechanism.
Impact Logic / Cost of Inaction
Formula:
Annual AP spend ÷ 365 × days paid early = average float released early
What this means:
When invoices are paid early, working capital leaves your account before payment is actually due. That cash either stops earning return for you or forces the business to replace avoidable float with borrowing.
Worked example:
$8M annual AP spend
5 days average early payment
4.25% yield on retained cash
Average float released early:
$8,000,000 ÷ 365 × 5 = $109,589
That is approximately $110,000 of your own cash leaving the business early for no payment-timing benefit.
Annual yield lost at 4.25%:
$109,589 × 4.25% = $4,658/year
If the company carries a revolving line of credit at 8.5%, the same float costs:
$109,589 × 8.5% = $9,315/year in avoidable interest
Combined annual effect:
Approximately $14,000 per year from a process issue that requires no software, no vendor negotiation, and no added headcount to correct.
Cost of this control:
Behavioral discipline and one written rule. No software. No vendor. No fee.
When It Stops Working
Your bank debits on approval, not on scheduled date.
In some platforms, selecting a future date does not preserve float because cash leaves immediately when payment is approved. Test actual debit behavior before building the process around scheduled release timing.
Due dates in the ERP are wrong.
If vendor terms or due dates are not maintained correctly in the accounting system, the framework runs on false data. Audit vendor terms periodically.
Annual AP spend is too low.
If annual Accounts Payable volume is below approximately $500K, the float benefit may be too small to justify the behavioral overhead required to maintain the control.
ACH timing cannot be controlled and no alternative mechanism is used.
If the bank platform defeats scheduled timing and no substitute mechanism is adopted for affected vendors, the framework will not deliver the expected float benefit. For check-eligible vendors, see FF-AP-002.
Support Files
Changelog
| Version | Date | Description |
|---|---|---|
| 1.0 | Apr 11, 2026 | Initial publication |
Field Notes
What was attempted: Applied the 3-business-day payment window rule to a bi-weekly check run. Shifted from paying everything in the queue to releasing only invoices due within the window.
What failed: QuickBooks does not support future-dated ACH debits. Scheduled payments debited the account immediately on approval. First two weeks of “future-dated” payments left the account on the same day as the old process. No float was preserved.
What was changed: Moved from bi-weekly to weekly check runs on Thursdays. Applied strict due-date filter at each run. Stopped using QuickBooks payment scheduling entirely — used it only for invoice tracking, not for payment timing. Payments released manually through the bank platform on run day only.
What improved: Average days early paid dropped from 11 to 2.5 within six weeks. On approximately $6M annual AP spend, recovered roughly $70K in average float that had been leaving the account early. Reduced one LOC draw in Q3 that would have cost approximately $2,800 in interest.
When the fix backfires: Breaks down during month-end close when the controller is occupied with reconciliation and the weekly run gets skipped. When the run is missed, invoices pile up and the next run pays everything regardless of due date — reverting to the old pattern for that cycle.
The strongest part of this framework is the way it separates payment timing from invoice approval. In smaller companies those usually get treated as the same thing, which is where the leakage starts. The “3 business days” rule is simple enough to use without turning AP into a bureaucratic mess.
What stood out
The failure mode is real. Bills often get paid because they are sitting in the batch, not because they are actually due.
Where I would push further
The framework should stay explicit that bi-weekly runs create a structural problem unless approval and release are separated.
Subscribe to updates on this framework
Get notified when this framework is updated or when a new Field Note is published.
Framework: Accounts Payable Timing Governance
Framework ID: FF-AP-001