.png)
“We’ll get it tomorrow.”
That sentence shows up in support tickets, status pages, and product copy all the time. It sounds clear. On a payment rail, it often isn’t.
Tomorrow for a person is the next calendar morning. Tomorrow for ACH or EFT is the next day the banks are open, after the cutoff your processor actually uses. Those are not the same thing. When your UI says one and the rail does the other, customers think you’re late, ops thinks the queue is broken, and nobody trusts the timestamps.
Cutoffs are the real clock
A debit scheduled Friday at 4:30pm is not Monday morning money just because the weekend is two days.
Most rails have a same-day window and a next-day window. Miss the cutoff and the file goes out on the next processing day. That next processing day might be Monday. It might be Tuesday if Monday is a holiday. It might be later if your processor batches once and your bank is on a different clock.
Product teams love to hide this. They show “pending” and hope the money lands soon enough that nobody asks. Ops teams live it every Friday afternoon when the queue fills with items that look overdue but are waiting on a calendar nobody put in the app.
If you only store “created_at” and “expected_by = created_at + 1 day,” you will lie to someone. The expected date has to come from a bank calendar plus a cutoff, not from Date.now() + 86400000.
Weekends and holidays are not edge cases
In Canada and the US, bank holidays are ordinary. Thanksgiving (different dates), Boxing Day, Canada Day, Labor Day, the long weekends that stack with Christmas. A return window that “takes two business days” can stretch across five calendar days without anyone doing anything wrong.
Support still gets the ticket on Saturday: “Where’s my money?” The honest answer is “the banks are closed,” but your status page said pending until tomorrow on Thursday night, and tomorrow was Friday, and Friday was a holiday in one country but not the other.
Cross-border products feel this twice. US ACH and Canadian EFT do not share a holiday list. A transfer that looks same-week in one country can sit idle in the other. If your product only knows “business days” as Monday–Friday with no holiday table, you will keep promising dates that cannot happen.
”Pending until tomorrow” is vague on purpose — and that backfires
Vague copy feels safe. “Funds usually arrive within 1–2 business days.” “Pending until tomorrow.” “Processing.”
Customers read that as a promise. Ops reads it as a shrug. Finance reads it as a recon item that will age.
Be specific when you can. Say which cutoff you missed. Say the next bank day you expect the file to clear. Say when a return can still come back. People will wait for a clear date. They will not wait calmly for a fuzzy one that keeps sliding.
The worst version is a countdown that ticks on calendar days. “Arrives in 24 hours” on a Friday evening is how you train users to open tickets on Saturday morning.
Return windows overlap holidays and surprise everyone
Returns do not respect your sprint board. An NSF, account closed, or unauthorized return can arrive days after you thought the payment was done. If that window overlaps a long weekend, the return lands on a Tuesday that feels like “way too late” to everyone who only watches the calendar.
So you need two clocks in the product, not one:
- When we expect the money to move (settlement / availability).
- When we still treat it as reversible (return window).
Cleared-looking is not final. That is a separate post. The bank-day version of that lesson is simpler: do not close the ticket or release the goods solely because “tomorrow” passed on a wall calendar. Close it when your return window, counted in bank days, has actually run out.
Put the bank calendar in the product
Ops usually knows this. Someone has a spreadsheet, a sticky note, or tribal knowledge about “don’t promise Monday if we miss Thursday cutoff.” That knowledge dies when that person is on vacation.
Encode it.
- A holiday calendar for each country you settle in.
- Cutoff times per rail and per processor, including same-day vs next-day.
- Expected-date functions that take “submitted at” and return the next valid bank day after cutoff.
- Queue SLAs measured in bank days, not calendar days.
- Customer-facing copy generated from those same functions, so support and the UI say the same sentence.
You do not need a perfect Fed or Payments Canada feed on day one. A maintained table plus a clear owner beats a hardcoded “+1 day” forever. Review it before year-end. Add provincial or state quirks when you actually hit them. Log when reality disagrees with the table so you can fix the table.
A Friday example worth remembering
Someone schedules a debit Friday after cutoff. Your app says “tomorrow.” They expect money Monday morning. The file goes Monday. Settlement is Tuesday. Monday was a holiday in their province. Support opens three tickets. Finance sees a recon exception. Product wonders why “the payment system is unreliable.”
Nothing failed. The language failed.
Change the copy to “next bank day after cutoff,” show the date, and the same flow feels boring and trustworthy. Boring is the goal.
What to check this week
- Does any screen promise “tomorrow” or “same day” without reading a cutoff?
- Do your SLAs and queues count Saturday and holidays as working days?
- When a return arrives after a long weekend, does it land in a queue with a reason, or as a mystery credit?
If those answers are fuzzy, start with the calendar. It is a small table. It removes a surprising amount of drama from ACH and EFT work.
Futurify builds the software around your payments: the calendars, the cutoffs, the states, and the queues that match how banks actually move money. We don’t hold funds. If you want to talk it through, email us at hello@futurify.io.