Cutoff Times: The Deadlines That Rule the Night

"Why does the claims file have to be in by 23:00?" "It just does." That exchange, or one like it, has taken place in every shop that runs a batch night. Cutoff times are the legislation of the night. They decide when partners must deliver, when jobs may start, and which late file gets processed tomorrow instead of tonight. Yet in most shops nobody can explain where they came from. They are written down nowhere a partner can see. The first anyone hears of a miss is a wrong report the next morning. The cutoff itself is untroubled by any of this. It falls at 23:00 whether or not anyone can say why.

This article treats cutoffs as the designed objects they ought to be. You will see why they exist at all and how each one is derived by working backward from a morning deadline. You will see what should actually happen to a file that misses one, and how timezones and clock changes quietly sabotage them. You will also see how to negotiate and publish a cutoff calendar that every team and partner can read. It is part of our Nightly Batch Ecosystems series and builds directly on The Anatomy of a Batch Night. That article's invented insurer, Harborview Mutual, supplies the worked examples here too.

What a Cutoff Is (and What It Is Not)

A cutoff time is the moment a batch process stops waiting for input and proceeds with whatever has arrived. That definition has a sharp edge. A cutoff is not a request, a target, or an SLA courtesy. It is the boundary of a decision. At 23:00 Harborview's consolidation step will run. The only question a cutoff answers is which files are inside tonight's batch and which are outside it. It is not interested in follow-up questions.

Three distinctions keep cutoff conversations honest:

• Arrival cutoff vs processing deadline. An arrival cutoff bounds when input must land ("claims files by 23:00"). A processing deadline bounds when output must exist ("morning reports by 07:30"). The first is enforced by you; the second is imposed on you. Every arrival cutoff in your night is ultimately derived from some processing deadline downstream.
• Internal vs external ownership. Harborview owns its 23:00 claims cutoff and could move it. The mail vendor owns the 05:30 print deadline, and no amount of internal urgency moves it. Knowing who owns each deadline tells you which ones are negotiable and which are walls.
• Hard vs soft. A hard cutoff triggers an automatic consequence (the batch runs without you). A soft cutoff triggers a human decision (an operator decides whether to wait). Both are legitimate; the failure pattern is the unlabeled cutoff that everyone treats as soft until the one night it mattered.

Why Cutoffs Exist: The Backward Arithmetic

Cutoffs exist because a dependency chain cannot start until its input is closed. Everything downstream needs a start time it can rely on. Without a cutoff, one late partner holds the entire night hostage — and with it every other partner's processing, the ledgers, the reports, and the print run. A cutoff converts an open-ended wait into a bounded one. That is the whole trick, and it is enough.

Where should the boundary sit? Not where habit put it — where arithmetic puts it. The method is backward scheduling. Start from the hardest external deadline at the end of the night. Subtract each step's realistic duration, plus a slack allowance, walking back to the start of the chain. For Harborview's main chain:

05:30  print file must reach mail vendor        (external, hard)
-0:25  report + print file generation           => must start by 05:05
-0:35  slack for the whole chain                => plan to start 04:30
-1:20  warehouse load                           => must start by 03:10
-0:45  general ledger posting                   => must start by 02:25
-2:10  adjudication run (current p90 duration)  => must start by 00:15
-0:45  claims consolidation                     => must start by 23:30
-0:30  settle checks + operator margin          => CLAIMS CUTOFF 23:00

Two things about this arithmetic matter. First, use realistic durations — the ninetieth-percentile night, not the best night. Otherwise, the cutoff will be a lie that only holds when nothing goes wrong. Second, the derivation is the cutoff's documentation. When a partner asks "why 23:00?", the answer is this ladder. When any rung changes — the adjudication run grows, the vendor moves its deadline — the cutoff must be re-derived. It must not be defended out of nostalgia. I once inherited a cutoff nobody could derive; it predated the job it was protecting. A cutoff nobody can derive is a fossil. Fossil cutoffs are one of the first things to re-examine when the batch window shrinks. They are precise, confident, and about a different night.

The Cutoff Calendar

Harborview keeps its cutoffs on a single page called the cutoff calendar — one row per feed. The calendar is visible to operations, the service desk, and (in a partner-facing version) to the senders themselves. Here is the daily portion:

Notice the shape of a good calendar row. It names the deadline's owner. It states the grace period explicitly instead of leaving it to folklore. The "if missed" column is filled in before the miss happens, in daylight, by people who are not panicking. Notice also the cycle column hiding in the row names — daily feeds, pay-cycle feeds, month-end feeds. Month-end is where calendars earn their keep: volumes double and extra feeds appear. A night that fits comfortably on the 12th can overflow on the 1st. The 1st, to its credit, has never been late.

What Actually Happens to a File That Misses the Cutoff

The measure of a mature batch ecosystem is not that cutoffs are never missed — partners are weather. It is that a miss lands in a pre-decided path instead of a 23:10 argument. There are only four standard fates for a late file, and every feed should have one of them written down:

1. Roll to the next cycle. The default for high-volume daily feeds: the file waits, clearly quarantined in a holding folder, and joins tomorrow's batch. Cheap, safe, and honest — the business consequence is one day's delay for one sender's data, borne by the sender who was late.
2. Supplemental run. A second, smaller consolidation later in the night sweeps up stragglers — Harborview does this for the lockbox file at 04:00. Only offer this where the chain has real slack and the downstream jobs are safe to run twice. The moment a supplemental run exists, files will arrive aimed at it.
3. Exception run with approval. A human weighs the business cost and may order a late run, accepting a compressed or overrun night. This is the right fate for the rare, high-stakes miss — a payroll input on a pay night. It belongs in a runbook with named approvers. The decision trades tonight's safety margin for one feed's timeliness.
4. Reject and resend. For files that arrive too stale to use or fail validation, the file goes back with a machine-generated reason. The sender's next delivery then starts clean. Rejection needs the most careful communication and the clearest logging, since it is the fate most likely to be disputed.

Which fate fits which feed follows from three questions. How much slack remains downstream at the moment of the miss? Can the consuming jobs absorb data twice without double-posting? What does a one-day delay actually cost the business? The second question is the one most often skipped — and it is load-bearing, because late files are the leading manufacturer of duplicates. A partner whose 23:20 file rolled to the next night will often "helpfully" resend everything at 09:00. Now two copies sit in the inbound folder. If the consuming chain is not idempotent — safe to feed the same data twice — a missed cutoff mutates into a double-processing incident, which is strictly worse. The defenses (processed-file ledgers, business-date checks, quarantine folders) are covered in safe reprocessing patterns.

Acme learned the supplemental-run lesson from its own arrival logs. A 04:00 sweep was added for one partner whose file kept landing at 23:20. It worked: that partner's data made the night without anyone arguing at 23:10. Within a quarter two other partners had noticed the sweep. Their files had drifted toward 03:30 as well. By then, the main consolidation was running on half the volume. The "supplemental" run had become the real one, with no slack behind it. A ninety-night query made the drift visible. The calendar was republished with an honest cutoff. The sweep became an exception path with a named approver. Nobody had broken a rule. The rule had quietly moved, and the calendar had not.

One more trap rides with every late file: the as-of date. A claims file named with a YYYYMMDD business date that arrives after midnight carries yesterday's date into today's folder listings. Process files by the date token in the name — the business date the sender stamped — never by arrival time. Keep the two dates from ever being confused by following the conventions in datestamp formats that sort. Midnight is where business dates go to get confused.

Timezone Reality Across Partners

The moment two organizations share a deadline, someone must answer: 23:00 by whose clock? Harborview's claims partners sit in three timezones; the card processor publishes its schedule in a fourth. Cutoff disputes between partners are timezone bugs more often than they are lateness — both sides genuinely delivered "on time" by their own wall clock. Both clocks were right. That was the problem.

Four rules keep clocks from eating your night:

• Publish every cutoff with an explicit timezone, spelled out ("23:00 Central, the receiving server's local time"), never implied. The receiving system's clock is the natural arbiter, so say so in writing.
• Beware daylight saving time twice a year. Clock-change weekends un-align schedules that agreed all year. A partner whose region shifts on a different date, or not at all, drifts an hour for weeks. The spring change also simply deletes an hour from one batch window. A night that normally finishes at 05:10 finishes at 06:10 by the new clock and misses the print run. Put both change weekends on the operations calendar and re-check the tight cutoffs around them.
• Keep server clocks disciplined. Cutoff enforcement compares file arrival timestamps to a deadline; if the transfer server's clock drifts, the comparison lies. Time synchronization on every machine in the chain is table stakes.
• Log in one timezone, display in local. Reconstructing a cross-partner incident from logs in four local timezones is misery. A consistent log timezone (many shops use UTC) with local display for humans keeps the record comparable.

The deeper patterns of scheduling across systems that share no clock — coupling, drift, and slack design between independent organizations — are the territory of our server-to-server exchange patterns series.

Enforcing Cutoffs Without Watching the Clock Yourself

A published cutoff is only as real as its detection. The failure you must engineer away is discovering the miss at 06:00. The goal is an alert at 23:00, when options still exist. You can call the partner, invoke the exception path, or consciously let the batch roll on. Two mechanical pieces deliver that:

First comes an expected-file check at the cutoff moment. This automated step runs at 23:00 and answers "is everything that should be here, here?" It alerts on absence, not just on failure. Absence detection is its own discipline, covered in freshness checks and expected files. The batch-night version can be pleasingly blunt. In Sysax FTP Automation, for instance, the pattern is a scheduled task at the cutoff. It attempts to collect the expected files and treats "nothing there" as an error. Its error handling then fires an email notification. A missing claims batch therefore pages someone while the phone call can still change the night.

Second, an arrival record you can hold up in a dispute. When a partner insists the file went up at 22:58 and your batch says otherwise, the transfer server's activity log is the arbiter. Every session, upload, and timestamp is recorded by the machine that owns the deadline clock. A server that logs to both file and database, as Sysax Multi Server does, lets you answer "when did partner B's files arrive over the last ninety nights?" as a query rather than an archaeology project. That arrival history is also exactly the evidence you need when renegotiating a cutoff with data instead of anecdotes. Reading those logs fluently is a skill of its own; see reading transfer logs.

Negotiating and Publishing the Calendar

Cutoffs sit between organizations, so they are negotiated objects — and the negotiation goes better when you arrive with the backward arithmetic. Show the partner the ladder from the 05:30 print deadline back to their 23:00 slot. The conversation stops being "your rule" and becomes "our shared constraint." In the other direction, when a partner pushes for a later cutoff, the ladder tells you precisely what it would cost. It shows which run must compress and which slack disappears. It tells you whether the answer is genuinely no or merely "not for free." I have walked a partner down that ladder once and never been asked "why 23:00?" by them again.

A few practices make the calendar durable:

• One page, one owner. The calendar lives in one place, has a named owner, and every partner-facing copy is generated from it. Two calendars will disagree within a quarter.
• Every row carries owner, grace, and consequence. A cutoff without a written consequence is a suggestion.
• Changes get notice periods. Moving a cutoff is a partner-facing change. Give the same notice you would want. Version the calendar so "which cutoff was in force that night" is answerable later. Setting these expectations formally — delivery windows, incident communication, maintenance notice — is the SLA discipline covered in our B2B partner exchange series.
• Review on a cycle. Re-derive the arithmetic whenever a chain step's duration changes materially, and at least twice a year around the clock changes. A calendar that is never re-derived is drifting toward fossilhood one quarter at a time.

Deadlines You Can Defend

A cutoff is a downstream deadline minus the work in between. It is derived, owned, published, enforced by detection at the moment it falls, and paired with a pre-decided fate for whatever misses it. Get those five properties in place and cutoffs stop being folklore and start being infrastructure. They are boring, visible, and defensible when a partner, an auditor, or your own morning-after review asks why the night ran the way it did. The answer to "why 23:00?" is now a ladder, not a shrug.

The natural next steps in this series: Mapping Batch Dependencies shows how to discover the real chain your arithmetic must model. And Catch-Up is the playbook for the mornings when the deadline lost anyway. For the broader question of when a whole window stops fitting, see When the Batch Window Shrinks.

Frequently Asked Questions