COB and production support

Why Batch Success Can Be Misleading in T24

A completed job proves that processing reached a terminal state. It does not, by itself, prove that the correct records were selected, posted, exported, received, and reconciled.

For T24 support teams reviewing COB, batch, and interface outcomes

By T24Guru Editorial·Published 30 April 2026·Updated 8 July 2026

Production support COB

Browse more Production support articles →

Technical success versus business success

Technical success means the program ended without a fatal runtime failure and the scheduler was able to continue. Business success means the expected population was processed and the resulting accounting, files, statuses, queues, and downstream acknowledgements agree with the business outcome.

These usually align, which is why a green status is useful. The risk appears when a program correctly processes an empty or incomplete selection, writes only control records, suppresses rejected work, or hands output to an interface that never completes delivery.

Common misleading-success patterns

An output exists but contains only a header, trailer, or incomplete detail.
A selection returns zero records despite expected business activity.
Processed counts do not reconcile with selected, rejected, or deferred counts.
A posting stage ends while repair or unauthorised items remain unexplained.
An internal status advances but the downstream system has not acknowledged receipt.
A retry or forced action creates duplicate or uncertain processing ownership.

Batch completion verification checklist

Use the sequence below as an evidence checklist. Exact enquiry names, files, commands, and operational actions vary by implementation and must follow the local approved runbook.

#	Check	How to verify
1	Terminal status is understood	Confirm the scheduler or job log reached the expected terminal state and review warnings as well as fatal errors.
2	Expected input population was available	Use an approved enquiry, report, or read-only query to establish the expected input count before comparing it with processing results.
3	Selection count is plausible	Compare the selected population with the business date, processing calendar, source state, and known workload for that run.
4	Every selected item is accounted for	Reconcile processed, posted, rejected, deferred, and exception counts. A successful job with unexplained records is not closed.
5	Exceptions and repair items are understood	Review the locally configured exception, repair, unauthorised, or rejection views. Record ownership and next action for every material item.
6	Output contains the expected business data	Verify record counts, control totals, structure, and representative content with approved tools; do not rely on file existence alone.
7	The downstream handoff completed	Confirm the receiving queue, file transfer, API, or interface produced the expected acknowledgement or independently verifiable receipt.
8	Control state matches business state	Check that business date, control records, service state, and dependent jobs advanced consistently rather than only one status changing.
9	Overrides and forced actions are evidenced	Confirm any override or forced processing was explicitly authorised, appropriate for the condition, recorded, and included in reconciliation. Authorisation alone does not prove correctness.
10	The result is reasonable against a comparable baseline	Compare counts and totals with a relevant prior run, allowing for weekends, holidays, month-end, migrations, and known business changes.

Observation before intervention

Capture logs, counts, timestamps, status history, ownership, and reconciliation evidence before restarting services, forcing statuses, replaying work, deleting files, or changing control records. Those actions require authorised local procedures and an explicit duplicate-processing assessment.

Why COB amplifies the risk

COB is a chain of dependent stages. A technically successful step can provide the wrong population to the next step, which may then process it perfectly. That creates a sequence of green statuses around a business error.

Verification should therefore follow the flow of data and control: expected input, selection, processing, exceptions, output, handoff, acknowledgement, and final reconciliation. A status should be one item of evidence, not the entire conclusion.

A practical closeout statement

Before closing the batch step, confirm that you can evidence this statement:

The step reached the expected terminal state, the expected population is accounted for, exceptions and authorised interventions are understood, downstream receipt is proven, and control totals reconcile to the business outcome.

When any part is uncertain, record the gap and escalate with the evidence already collected rather than converting uncertainty into a confident green tick.