Daily cash position: Automated Clearing House, Real-Time Payments, card by 4 p.m. or hold

This guide sets a 4 p.m. daily cash cutoff and assigns ACH, RTP, and card settlements to their proper windows.

It gives rules for when speed justifies RTP fees and when card items wait for next-day reconciliation.

How the 4 p.m. cutoff actually works

The 4 p.m. cutoff is not a single deadline; it is three different clocks running at once, and only one of them is actually binding. ACH moves in batch windows, and each receiving depository institution sets its own same-day ACH cutoff inside the network's published windows. That means the operative question at 4 p.m. is not "is it too late to send an ACH?" but "has my originating bank's same-day window for this file already closed?" The practical rule: pull your treasury management agreement and locate the exact same-day ACH cutoff your bank applies to origination files, then work backward from it for file build, approval, and release. If that cutoff falls at or before 4 p.m. local, the 4 p.m. decision point is really a file-completion deadline, not a send deadline.

RTP behaves nothing like ACH on this axis. It is a real-time rail that settles immediately, around the clock, with no batch window to miss. The 4 p.m. cutoff has no bearing on whether an RTP payment settles today, because RTP does not queue for a window — it either processes or it does not. What 4 p.m. still governs is your internal workflow: who approves the payout, who confirms the beneficiary, and who books the entry before the reconciliation cycle closes. Treat RTP as speed you buy, not speed you schedule.

Card settlements sit on a third clock entirely. Card networks settle on their own cycle, and the funds land in your account on the network's schedule, not yours. That makes card activity a next-day reconciliation item by default: you match settlement reports to processor deposits after the fact rather than initiating anything at 4 p.m. The check here is whether your reconciliation tooling ingests processor settlement files automatically or whether someone is still matching spreadsheets by hand — SabPaisa notes that at lower volumes, teams reconcile settlements manually using spreadsheets and transaction reports, which is exactly the pattern that breaks as volume grows.

So the mechanism at 4 p.m. is a routing decision across three rails with three different settlement behaviors. ACH: batch, bank-specific cutoff, same-day or next-day depending on whether you made the window. RTP: immediate, windowless, gated only by your own approval and reconciliation process. Card: network-scheduled, reconciled after the fact. The 4 p.m. cutoff binds hardest on ACH, is irrelevant to RTP settlement, and is a workflow marker for cards.

Run this as a daily control rather than a one-time setup. Each business day before 4 p.m., confirm the ACH file is complete against your bank's stated cutoff, confirm any RTP payout has cleared approval and beneficiary checks, and confirm card settlement files are queued for reconciliation. Kani Payments frames reconciliation as a structured daily control with defined logic and consistent outputs; that is the right posture here. The cutoff works only if the checks behind it run every day.

What the evidence actually establishes

The evidence base for a 4 p.m. cash cutoff is narrower than most treasury teams assume, and it points in one direction: the deadline is a settlement-and-reconciliation control, not a payment-speed decision. FinTech Weekly names the constraint directly in "The Real Bottleneck in Finance Isn't Payments. It's Settlement." — the bottleneck sits downstream of initiation, in settlement and the reconciliation that follows it. That framing matters because it tells you what the 4 p.m. cutoff is actually for. If initiation were the constraint, moving money faster would fix the problem; because settlement is the constraint, the cutoff exists to put every non-time-critical item into a batch that clears and reconciles on a known schedule.

Kani Payments describes reconciliation as "a structured daily control, with defined logic, consistent outputs and clear oversight," and lists catching unmatched items, data quality issues, and variances "as they occur" among its core benefits. Read that as an operating instruction: a daily cutoff is the point at which the control runs. The check for your own desk is whether the 4 p.m. decision produces a defined output — matched items, unmatched items, variances, and an owner for each — or merely a queue of payments released. If it produces only the latter, you have moved the bottleneck rather than managed it.

Equali's model reinforces the same rule from the automation side: connect sales channels, payment providers, and accounting systems, then reconcile payments, orders, and settlements in real time, with discrepancies surfaced and routed into approval workflows. The practical test is whether your card settlements arrive as a reconcilable feed tied to orders and deposits, or as a lump sum you must decompose by hand the next morning. If it is the latter, card activity belongs in next-day reconciliation by default, and the 4 p.m. window should be reserved for items you can match the same day.

What the evidence does not do is price the trade. None of these sources quantifies the RTP network fee against a measured speed benefit, and none supplies a settlement lag figure you can plug into a model. So treat the comparison as a method, not a number: for each time-critical payout, estimate the value of same-day arrival to the recipient or to your own cash position, compare it against the RTP network fee quoted by your institution, and route to RTP only when the benefit exceeds the fee. Everything else initiates by the bank's ACH cutoff.

The defensible default follows from that: initiate non-time-critical ACH debits and credits by the bank's ACH cutoff, reserve RTP for time-critical payouts whose quantified speed benefit clears the network fee, and treat card settlements as a next-day reconciliation item. The binding constraint is settlement and reconciliation capacity, so the 4 p.m. decision should be judged by whether the day closes matched — not by how fast any single payment left.

ACH vs RTP vs card at 4 p.m

Head-to-head at the cutoff, ACH wins the default. It is a batch rail with no meaningful per-payment network cost for standard U.S. transfers, and it clears in the same-day window as long as the batch is in before your bank's same-day ACH cutoff. For every non-time-critical payout — supplier payments, scheduled disbursements, routine returns — the check is simple: is this batch assembled and approved before that bank-specific deadline? If yes, ACH is the rail. Speed it cannot deliver, but speed is not what these payments need.

RTP wins only on a payout-by-payout basis, and the test is arithmetic, not instinct. RTP settles in real time, runs around the clock, and charges a network fee per transaction. That fee is worth paying only when the cost of delay is quantifiable and larger — a late fee you would incur, a relationship at risk, a counterparty requirement with a hard deadline. The working rule: write down what an hour of delay costs for this specific payment, compare it to the per-transaction network fee, and route to RTP only when the benefit clears the fee. Everything else stays in the ACH batch.

Card is not a payout rail at all, and treating it as one is the mistake that breaks the cutoff. Card settlements arrive as a batch file from the processor, and the operator's job is reconciliation — matching that file against orders and bank deposits, not initiating anything. Payments-operations platforms like Kani Payments and Equali are built around exactly this: matching fragmented settlement files across channels automatically, with ReconcileOS reporting teams save 15+ hours monthly once settlement syncing is automated. The decision at 4 p.m. is therefore not "should we push cards faster" but "is today's settlement file received, matched, and exception-flagged before the team leaves."

The winner for the 4 p.m. decision is therefore a routing rule, not a rail: ACH by default, RTP by exception with a fee-versus-benefit test, card as a next-day reconciliation item. Each payout gets one question — is it time-critical, and if so, by how much in dollars — and the rail choice follows from the answer rather than from habit.

Costs and numbers that matter

The cost story behind a 4 p.m. cutoff splits into three very different line items, and treating them the same is how teams end up overpaying for speed they don't need. The first line item is ACH. For standard U.S. domestic transfers, the ACH network cost is effectively zero — the real cost is operational: getting the batch assembled, validated, and submitted before your bank's cutoff. That means your ACH expense is measured in staff minutes, not per-transaction fees, and the way to control it is a disciplined batch calendar, not a cheaper rail.

The second line item is RTP, and here the per-transaction network fee is set by your bank — it is not a published universal rate you can assume. Before you route any payout to RTP, pull the exact figure from your bank's RTP pricing schedule and put it in your routing policy as a hard number. The decision rule is simple: send a payment over RTP only when the quantified value of the time saved exceeds that fee. A payout that must land today to release a shipment clears that bar easily; a routine vendor payment does not.

The third line item is the one teams underestimate: manual reconciliation of settlements, especially card settlements that arrive as next-day batches. The automation saving quantified above — ReconcileOS's 15+ hours monthly of manual matching eliminated — is the cleanest available proxy for what the absence of daily cutoff discipline actually costs you. Analyst hours spent matching settlement files by spreadsheet after the fact are the baseline you are choosing when you let cutoffs slip. At lower transaction volumes, manual reconciliation of settlements using spreadsheets and transaction reports is workable, as SabPaisa notes, but it scales badly.

Put the three on one sheet:

The check to run this week: ask your bank for the RTP pricing schedule in writing, time one full manual card settlement reconciliation, and multiply that hours-per-session figure by your working days to get your own monthly number. If it approaches the monthly saving ReconcileOS reports for automated matching, as priced above, the automation case writes itself — and your cutoff policy is already paying for its own enforcement.

What the evidence does NOT establish

Before you hard-code a 4 p.m. cutoff into your treasury policy, be clear about what the evidence in front of you does not tell you. The strongest claim the sourcing supports is directional: FinTech Weekly argues that settlement, not payment initiation, is the real bottleneck, and the reconciliation vendors (Kani Payments, Equali, AutoRek, ReconcileOS) demonstrate that matching and exception-handling, not transfer speed, consume the operating day. That is enough to justify a cutoff as a control. It is not enough to justify any specific dollar figure on any specific rail.

First gap: fee schedules. None of the sources quoted here contain RTP network fees, same-day ACH pricing from your bank, or card settlement costs. Any per-item comparison you build must be pulled from your own treasury management agreement and processor statements. The method is simple and number-free: for one representative week, log every item routed to each rail, then divide total rail charges by item count to get your own blended per-item cost. Use that number in the RTP-versus-ACH decision, not a benchmark you read somewhere.

Second gap: the cutoff time itself. Same-day ACH windows are set per originating depository financial institution inside the network's broader schedule, and your bank's window may sit earlier or later than 4 p.m. Verify it in your treasury management agreement, and confirm whether your bank imposes an earlier internal submission deadline than its stated ACH cutoff. A policy keyed to a time your bank does not actually honor fails silently — you discover it the first day a batch misses.

Third gap: end-to-end speed. RTP settles in seconds at the network level, but that is not the same as money reaching a counterparty faster. If your internal flow requires dual approval, a callback verification, or a manual reconciliation step before release, those steps — not the rail — set your true delivery time. Time the full path, initiation to confirmed receipt, on both rails for a sample of payments before concluding RTP buys you anything.

Card settlements are the clearest case for humility: settlement timing is set by processor and acquirer agreements, and the sources here speak only to the reconciliation side. Treat the card rail's arrival time as an observed fact to measure, not an assumption to schedule against.

The practical takeaway: the sourced evidence establishes that reconciliation, not speed, is where hours are lost — ReconcileOS reports saving 15+ hours monthly by automating settlement matching, and SabPaisa notes manual reconciliation is the default at lower volumes. It does not establish your cutoff time, your fees, or your true RTP advantage. Those three numbers come from your own operations, measured before the policy is written.

$48,000 payout at 3:45 p.m

Consider an illustrative $48,000 domestic vendor payout that is not time-critical, initiated at 3:45 p.m. local time. For the worked example, assume — as placeholder figures you must replace with your own treasury management agreement — that the bank's same-day ACH cutoff falls at 4:00 p.m. and its quoted RTP network fee is $0.045 per transaction. Those four inputs are enough to run the decision, and the decision is ACH.

Checkpoint 1 is rail choice. Because the payout is non-time-critical, the speed advantage of RTP has no quantified dollar value here — nothing in the payment's purpose depends on the recipient receiving funds minutes rather than hours sooner. ACH, by contrast, carries effectively zero hard network cost for this transaction. Routing it over RTP would add the quoted per-transaction fee with no offsetting benefit, so the default holds: ACH debit or credit, initiated before the bank's ACH cutoff. RTP is reserved for payouts where the speed benefit can be priced and exceeds the network fee.

Checkpoint 2 is cutoff compliance. At 3:45 p.m., the initiation sits inside the 4:00 p.m. same-day ACH window, so the payment can settle same-day rather than rolling to the next banking day. The margin is fifteen minutes. That is thin enough that the practical control is not the clock on the wall but the bank's actual submission deadline and the time required to validate the batch before release. A file that clears internal approval at 3:58 p.m. is not the same as a file the bank has accepted at 3:58 p.m.

Checkpoint 3 is the reconciliation side. Card settlements are not part of this payout at all; they belong to the next-day reconciliation queue, where they are matched against processor settlement reports rather than treated as a same-day cash event. That separation matters because the 4 p.m. cutoff is a settlement-and-reconciliation control, not a payment-speed decision — a point FinTech Weekly makes directly in its analysis of where finance operations actually stall. The bottleneck is matching and confirming, not moving the money.

The arithmetic is straightforward and worth stating plainly. The bank-quoted RTP fee against a $48,000 payout is a rounding error in percentage terms, but the rule is not about the size of the fee — it is about whether the fee buys anything. Here it does not. Multiply the same logic across a daily batch of non-time-critical payouts and the discipline compounds: every unnecessary RTP routing is a cost with no corresponding benefit, and every missed ACH window converts a same-day settlement into a next-day item.

The operating rule for this scenario: initiate the ACH batch by the bank's cutoff, confirm acceptance rather than assuming it, route to RTP only when the speed benefit is quantified and exceeds the fee quoted in your bank's RTP pricing schedule, and park card settlements in the next-day reconciliation queue. The 3:45 p.m. initiation is defensible; the fifteen-minute buffer is the part to watch.

Decision rules for the 4 p.m. cutoff

Apply the 4 p.m. cutoff as a routing decision, not a speed contest: classify each payout by whether it is domestic and whether it is time-critical, then route it through the branch that matches both facts. If a payout is domestic and non-time-critical, initiate it through ACH before the bank's same-day cutoff and treat ACH as the default rail. If a payout is time-critical and the quantified speed benefit exceeds the RTP network fee, route it to RTP even when that decision is made after 4 p.m. If a payout is time-critical but the speed benefit does not exceed the RTP network fee, hold it for the next ACH batch window instead of paying for faster settlement.

The first rule is the default because it covers the routine case: domestic, non-time-critical payouts do not need same-day funds movement, so they should follow the lower-cost batch path and be initiated before the bank's same-day ACH cutoff. The decision is made by classification, not by urgency felt at the desk.

The second rule is the only exception to the ACH default. "Quantified" means the benefit must be expressed as a documented amount or avoided cost, such as earlier availability of funds, avoided late fees, or a contractual service level, and then compared directly with the RTP network fee. If that comparison is not documented, the payout does not qualify for RTP under this rule.

The third rule prevents paying for speed that is not worth its price. A time-critical label alone does not justify RTP; if the quantified benefit is equal to or less than the RTP network fee, the payout waits for the next ACH batch window. This keeps the exception narrow and repeatable.

When classification is unclear, default to ACH and document the reason for any RTP exception. The rules are intentionally binary: a payout either has a documented speed benefit above the RTP network fee or it does not, and the 4 p.m. cutoff does not change that comparison.

What to do next

Frequently Asked Questions

What time is the daily cash cutoff for initiating non-time-critical ACH batches?

By 4 p.m., initiate every non-time-critical ACH batch.

When should time-critical same-day payouts be routed to RTP instead of ACH?

Route time-critical same-day payouts to RTP only when the quantified speed benefit exceeds the RTP network fee.

How should card settlements be handled in the daily cash position?

Hold card settlements for next-day reconciliation, since they are treated as a next-day reconciliation item, not a same-day cash item.

What is the real binding constraint in the daily cash process?

Settlement, not payment initiation, is the binding constraint.

At 4 p.m., what is the operative question for ACH rather than whether it is too late to send?

The operative question at 4 p.m. is whether your originating bank's same-day window for this file has already closed.

Where can you find your originating bank's same-day ACH window details?

Pull your treasury management agreement and locate the same-day ACH window for your originating bank.

Quick answers

Also worth reading: RTP vs Same-Day ACH: Fees, Routing, and the 24/7 Clock: RTP vs Same-Day ACH: Fees, · RTP vs ACH 2026 Payouts: Early-Pay Discount Math: RTP vs ACH 2026 Payouts: · 2026 Payout Costs: Bank Transfer (ACH) vs Real-Time (RTP) vs Stablecoin — Switch >$10k: 2026 Payout Costs: Bank Transfer