Batches view

Outcome

You can see exactly which outbound batches the gateway produced on each cron tick, what they contained, where they went, and which partners rejected them — at a glance, without diving into individual transactions.

Prerequisites

Scope	What it lets you do
edi.batch.read	View the batches list and detail
edi.transaction.read	Drill into transactions inside a batch

What a "batch" is in this context

A batch is one outbound bundle: one or more interchanges produced together for delivery to a single partner. Most commonly:

• One per partner per cron tick for SFTP partners.
• One per eligibility.sweep_queued event for batch eligibility.
• One per claim group for clearinghouses with size limits.

A batch can carry many transactions (claims) and many interchanges (when size or partner limit forces a split).

The list page

/batches filters:

Filter	Default
Date range	Last 7d
Partner	All
Source	All (claims, eligibility-sweep, auth-request)
Status	building / submitted / acknowledged / failed

Each row:

Column	Notes
Created	Server timestamp.
Partner	Display name.
Source	What triggered this batch.
Tx count	Number of transactions inside.
Interchange count	How many ISA envelopes the batch produced.
Status	Current state.
Total size	Bytes (helps spot oversized batches).

The batch detail

/batches/:id opens with three tabs:

Tab	Content
Overview	Header + batch-level metadata.
Transactions	The transactions inside this batch. Drill-through to /transactions/:id per row.
Activity	Build / submit / ack events with timestamps.

The Transactions tab is the most-used. Sort by claim status to see which inside a batch were rejected vs. accepted.

Source: claims

When the gateway's claim-submission-consumer picks events off the bus, it groups them per partner using batch-builder logic. The default grouping:

A claims batch is named for its window — e.g., claims-2026-04-25-1430 for the 14:30 UTC pick-up.

Source: eligibility sweeps

Each sweep produces one batch per partner, regardless of cadence. The batch's source is the sweep ID; from the batch detail you can navigate back to the sweep and see overall progress.

Source: auth requests

Auth requests are typically real-time (one ST per ISA per request) but can be batched when many requests queue up before submission. The batch detail names which auth requests it contained.

Steps to investigate a partner-rejected batch

A failed batch means the partner accepted the file at the transport level but returned a 999 / TA1 with rejections affecting many or all of its transactions:

1. Open the batch detail → Transactions tab. Confirm whether all transactions failed or just some.

2. Click into one failed transaction to read the specific 999 / TA1 reason.

3. If all transactions cite the same IK3/IK4 issue, the cause is at the batch / envelope level — wrong ISA08, mis-applied companion guide rule on every claim, etc. Fix once and replay the batch.

4. If only some failed, the cause is per-claim — bad source data on the failing ones. Fix the source claims; rebuild only those (see 8.2 — Replay & retry).

Steps to find oversized batches

Some partners cap batches harder than others. To audit:

1. Sort the list by Total size descending.

2. For partners with hard size caps, batches at or near the cap are at risk of partner-side rejection.

3. Tighten the partner's max_st_per_interchange (2.2 — Connection types) to force smaller splits. Future batches honor the new cap.

Steps to replay a batch

Replaying a whole batch is rarely the right call (cf. per-transaction replay), but for a batch where every transaction failed for the same envelope-level reason:

1. Open the batch detail. Confirm every transaction failed.

2. Click Replay batch (visible only when status is failed). The platform regenerates the batch from the underlying events; a fresh batch record is created. The original stays for audit.

3. Watch the new batch's progress. If the underlying envelope issue is fixed, the new batch should accept cleanly.

Validation

Check	Expected
Batches appear within a minute of submission	Yes.
Batch's tx count matches actual transaction-list count	Yes.
Failed batches' Activity tab has a clear failure reason	Yes.
Replaying a batch creates a new record (does not mutate the original)	Yes — original is immutable for audit.

Troubleshooting

Symptom	Cause	Fix
Empty batch (zero transactions)	Cron tick fired but the partner had no queued events	Expected; common for low-volume partners outside business hours.
Batch in building status for hours	batch-builder hung	Restart the consumer (platform admin); the next cron tick rebuilds.
Same source produced two batches at the same time	Race in the consumer; the events were split	Acceptable as long as each contains different transactions; the partner sees two ISAs and processes both.
Batch size unexpectedly large	Recent rcm-core push generated many simultaneous events	Tighten partner batch limits to force splits.

Next

8.5 — Routing simulator & precedence debugging