Bunch Cheque Acceptance Workflow: From Escrow to Reconciliation

A bunch cheque acceptance workflow is a custody process, not a batch OCR job. The terminal must separate each cheque, capture its evidence, hold the paper in escrow and preserve the option to return it. Only then can software decide which items to accept, endorse and store.

The device handles paper. XFS and the terminal application expose device state. ChequeDB turns the resulting images and MICR observations into structured fields, validation results, risk checks and review tasks. It can also orchestrate the decision exchange with the bank host and send an actionable outcome back to the terminal workflow. The device itself does not read the amount, payee or date, and it does not decide whether a cheque should be credited.

The acceptor is vendor hardware, not ChequeDB hardware. ChequeDB supports the intelligence and orchestration integration above that boundary. The bank must confirm the physical module's procurement, lifecycle, firmware, drivers, device software, maintenance and current vendor support for the exact configuration.

That separation is the foundation of reliable cheque management with approval, reconciliation and audit trails.

For the underlying module boundary, start with NCR SCPM cheque processing: hardware versus software.

Bunch cheque acceptance is an item-by-item custody workflow

A customer may insert a stack, but the system must never treat that stack as one indivisible object. Every physical cheque needs its own identity and lifecycle.

A production workflow should track two levels of state:

• Transaction state: the customer session, expected item count, deposit total, host reference and overall outcome.
• Item state: physical sequence, front and rear images, MICR observation, extracted fields, validation results, customer edits, host decision and final destination.

This matters because one bunch can contain several outcomes. A clear cheque may be accepted. A folded item may fail image quality. Another may have a numeric and written amount mismatch. A suspected duplicate may require review or return. The transaction is only controlled when the system can explain what happened to every item.

The system boundary: device, XFS, APTRA, ChequeDB and bank host

The clean architecture separates physical device control from cheque intelligence and bank authority.

For NCR SCPM deployments, the supported historical path runs from the hardware through the NCR XFS service provider and APTRA Bunch Cheque Acceptance Service into Advance NDC state processing. NCR's developer material describes direct programming against the historical Bunch Cheque Acceptance .NET API as unsupported. The practical integration question is not whether a USB cable exists. It is whether the supported XFS/NDC stack exposes each item's evidence before the paper leaves escrow.

ChequeDB sits above that device boundary. It can work with a supported NCR adapter or another vendor's SDK without making proprietary device structures the bank's canonical cheque record. See the broader hardware integration model for cheque acceptance.

1. Open the transaction before paper enters

The transaction identifier should exist before the shutter opens. The terminal records the customer session, device identity, location, software version and expected deposit context. It should also confirm that escrow, the return path and the intended storage bin are available.

This first step prevents an anonymous stack from entering the transport. It also gives recovery logic a durable transaction to find after a software restart or power loss.

Useful pre-insertion checks include:

• device health and sensor state;
• escrow and bin capacity;
• endorser availability where endorsement is required;
• network reachability or an approved offline policy;
• terminal clock and transaction sequence;
• ability to return items if the transaction cannot continue.

If the system cannot preserve or reverse custody, it should not accept the bunch.

2. Separate the bunch and assign physical sequence

The feeder draws cheques from the stack one at a time. Double-feed and thickness sensors detect items that may be stuck together. Mechanical deskew aligns the paper before imaging and MICR acquisition.

Each separated item receives an immutable sequence number such as transaction 8241, item 03. That identity follows the cheque through imaging, escrow, decision, endorsement and final storage or return. It must not be derived only from a temporary filename.

The workflow should retain device observations such as:

• double-feed retries;
• excessive thickness;
• measured skew;
• transport sensor sequence;
• item dimensions or unsupported media;
• separation failure and return status.

These are not OCR results. They are physical evidence that helps operations explain missing images, jams and count differences.

3. Bind the images and MICR observation to the item

The device captures front and rear images while the cheque moves through the transport. Applicable hardware may provide other channels, such as ultraviolet images. The MICR head acquires the magnetic signal from the control line.

The workflow binds these observations to the same item identity:

• original front and rear images;
• optional UV or endorsement image;
• image hashes and capture timestamps;
• raw magnetic MICR observation;
• transport and image-quality signals;
• device and software versions.

MICR acquisition is not full cheque parsing. The MICR control line supports routing, account and cheque-number processing. The amount, amount in words, payee, date, signature and endorsement require image recognition, validation or human review. The cheque data extraction workflow explains how those fields become structured operational data.

4. Keep the paper reversible in escrow

Escrow is the control point between capture and commitment. The physical paper remains staged while ChequeDB and the bank host process the electronic evidence. The system can still return the correct item if the customer cancels, a field is unreadable or the host declines the deposit.

No item should be endorsed or sent irreversibly to the main bin before its decision is final. Host approval alone is not physical capture. Physical capture alone is not core posting. Evidence upload is another distinct stage.

A useful item state model keeps these events separate:

PRESENTED -> SEPARATED -> IMAGED -> ESCROWED
          -> RECOGNISED -> VALIDATED -> DECIDED
          -> COMMITTING -> CAPTURED
          -> RETURNING -> RETURN_TAKEN or RETURN_RETRACTED

This distinction becomes essential when a terminal loses power between host approval and physical storage.

5. ChequeDB converts evidence into a decision package

While the paper remains in escrow, ChequeDB processes the images and device observations. It does not merely return one opaque score. It builds an item-level package that downstream systems can use.

The package can include:

• parsed and normalised MICR fields;
• courtesy amount and legal amount extraction;
• amount agreement or mismatch;
• date extraction and stale- or post-dated policy results;
• payee extraction and comparison where reference data exists;
• image-quality results and missing-image checks;
• exact and near-duplicate candidates across channels;
• risk signals with explicit reason codes;
• field confidence, model version and source crop;
• a straight-through, review or decline recommendation;
• the evidence needed for a reviewer or bank-host decision.

Recognition and policy remain separate. A model may read an amount as 125,000 with high confidence. Validation still needs to determine whether the numeric and written amounts agree. The host may then check the account, stop status, deposit limit and customer eligibility.

Developers can use the bank cheque OCR API for structured fields and validation output, while the orchestration layer manages the state and decisions around that output.

6. Orchestrate the bank-host decision per item

ChequeDB can coordinate the request to the bank host rather than leaving the terminal to assemble several unrelated service calls. The orchestration request carries the item identity, extracted fields, validation results, risk reasons, customer-entered amount and evidence references.

The bank host remains the authority for account and posting decisions. Its response should be explicit and item-specific:

• accept and capture;
• return to customer;
• move to an approved reject or retained-item destination;
• request customer confirmation or correction;
• hold for review under a defined policy;
• retry safely after a temporary host failure.

Each response should include a decision code, reason, policy version, host reference and expiry. A late or repeated response must not cause a second physical movement or duplicate credit. Idempotency keys bind the orchestration call to the original item and transaction.

For a mixed-decision bunch, the terminal receives a destination for every item. It should never infer the fate of item 03 from the result for the whole transaction.

7. Commit accepted items only after the physical move succeeds

An accepted item leaves escrow, receives the required rear endorsement and moves into secure storage. Where supported, a rear image captured after endorsement provides stronger evidence than a record that only says printing was requested.

The durable capture record should contain:

• endorsement text or template reference;
• endorsement command and outcome;
• post-endorsement image when available;
• destination bin and physical sequence;
• sensor confirmation that the item reached that destination;
• host approval reference;
• timestamp and terminal journal event.

The item becomes CAPTURED only after the device confirms the physical destination. If the item jams after host approval, the system enters recovery. It must not silently mark the cheque stored or ask the host to post it again.

8. Return rejected or cancelled items under positive control

Rejected items leave escrow through the re-bunching and return path. The terminal records which item identities were presented back to the customer and whether the customer took them.

A safe return flow distinguishes:

1. return commanded;
2. item reached the return position;
3. customer took the item;
4. timeout expired;
5. item was retracted to a defined bin.

RETURNED is too vague for custody. A cheque presented but not taken is operationally different from one collected by the customer. The system should preserve the physical destination, sensor evidence and notification or dispute workflow for each outcome.

Exceptions must preserve custody before throughput

The exception design is what separates a controlled deposit system from a successful demo.

Manual correction must also be controlled. Store the machine value, customer edit, operator correction and final host value separately. Record who changed what, why, when and under which approval rule.

Reconciliation closes the custody loop

Reconciliation is not a report added after processing. It is the proof that electronic records and physical paper remained aligned.

At transaction level, reconcile:

• inserted item count;
• separated and imaged count;
• accepted value and item count;
• returned, retracted and rejected count;
• physically stored count;
• host-approved and core-posted count;
• evidence-uploaded and clearing-submitted count.

At item level, the reconciliation record should connect the original image hashes, MICR observation, extracted and corrected values, decision history, physical destination, host reference, archive reference and downstream clearing status.

Count equality is necessary but insufficient. Ten image records and ten pieces of paper can still be wrong if item identities were swapped. Sequence, hashes and correlation IDs protect against that failure.

Operational dashboards should highlight unresolved states rather than collapse them into a generic failure total. Useful queues include host-approved but not physically captured, captured but not posted, returned but not taken, image uploaded but archive unconfirmed, and clearing-rejected items awaiting repair.

The operating principle

Bunch Cheque Acceptance works when every layer has a narrow responsibility and shares one item identity.

The hardware preserves physical custody. XFS or the vendor SDK exposes supported device actions. APTRA or the terminal application manages the customer and device sequence. ChequeDB supplies image intelligence, validation, risk checks, review and bank-host orchestration. The host applies account policy and posting authority. Clearing and archive systems complete the downstream lifecycle.

That model produces more than parsed fields or a risk score. It produces a controlled decision the terminal can execute, a record operations can reconcile and an evidence trail reviewers can defend.