The short version
| Question | X9.37 / image cash letter | NACHA ACH |
|---|---|---|
| What moves | Cheque images plus MICR and cash-letter data | Batch debit/credit entries and payment data |
| Carries an image? | Yes — front and usually back | No |
| Typical use | Cheque image exchange and clearing | Electronic payments, conversions, credits/debits |
| Key identifiers | Bundle, sequence, routing, account, cheque number | Company ID, SEC code, trace number, routing/account |
| Return path | Image return / return cash letter | ACH return codes and notifications of change |
| Operational owner | Clearing/image exchange team | ACH/payments operations |
What X9.37 is
X9.37 is an image exchange format used in cheque clearing. A file contains a cash letter with one or more bundles and items. Each item carries the cheque image, MICR line, amount, and sequence information so the receiving institution can process it as a cheque. The format is associated with Check 21 image exchange in the United States, but the underlying idea — exchange the image and data instead of the paper — is used in other image-clearing environments too.
The important implementation detail is not the file extension. It is the control total: the item count and amount totals in the file must reconcile to the bundle and cash letter. A file that parses but does not balance is not a successful clearing file.
What ACH is
ACH is a batch electronic funds transfer network. An entry identifies the receiver, the account, the amount, the effective date, and a SEC code that describes the payment context. Cheque-related ACH entries commonly appear when a cheque is converted at the point of purchase or via accounts receivable conversion, but the ACH entry is not a cheque image and does not carry the cheque’s front and back.
ACH has its own return process, notification-of-change rules, and settlement windows. Treat ACH origination as a separate integration with its own compliance, authorization, and reconciliation requirements — not as a file export from an OCR workflow.
Where they meet in a cheque workflow
- Capture the cheque image and MICR data.
- Extract and validate fields, including CAR/LAR agreement and date rules.
- Route exceptions to review; record the decision and evidence.
- Create the clearing artifact (X9.37, ACH, or another rail) through the bank’s system.
- Reconcile the item to the deposit, ledger, return, and settlement records.
The OCR/extraction layer is step 1–3. The clearing artifact is step 4 and belongs to a different system or a separately scoped integration. Do not collapse those boundaries in the architecture or the audit trail.
Integration checklist
- Field mapping: routing, account, cheque number, amount, date, payee, item reference, and the bank’s own IDs.
- Control totals: item count and amount totals reconcile at item, bundle, and file level.
- Idempotency: the same cheque image cannot create two clearing entries.
- Duplicate detection: check number, account, amount, date, and image similarity — not just a single field.
- Returns: map return codes back to the original item and reviewer decision.
- Audit trail: image, extracted fields, corrections, approvals, file ID, transmission response, and settlement reference.
- Retention: align image, file, and audit retention with bank policy and legal hold.
How Chequedb fits
Chequedb focuses on capture-adjacent extraction, field validation, review, approvals, and audit evidence. It can produce structured fields and reviewable records that feed a bank’s existing X9.37 or ACH pipeline. X9.37 generation, ACH origination, transmission, and clearing are deployment- and integration-specific; confirm the current scope before assuming the OCR response is a cash letter or an ACH file.
The API contract is documented in the bank check OCR API docs. The security and data-flow boundary is covered in the security and compliance hub.
Common mistakes
- Treating OCR success as deposit or settlement.
- Letting the CAR/LAR mismatch pass because both fields were “read.”
- Creating a file without reconciling control totals.
- Using one field for duplicate detection and missing the same cheque in a different channel.
- Losing the link between the return, the original image, and the reviewer decision.
- Assuming an ACH entry and an X9.37 item are interchangeable because both came from a cheque.