CTS-2010 cheque OCR + figures-vs-words parity + 90-day staleness check — cheque scanning automation in under 10 seconds per instrument.
Manual cheque scanning automation is the last paper-intensive step in mid-market accounts payable. Finance teams processing 80–200 instruments a month face three failure classes that no spreadsheet register catches uniformly.
A junior accountant reads the amount in words, reads the amount in figures, and visually confirms they agree. For 80 cheques processed on a Monday morning, this check is skipped or rushed on 15–20% of instruments. A single one-zero error — Rs. 50,000 written as "Five Thousand Only" — passes into deposit and returns with a return memo two banking days later, triggering a potential Section 138 exposure under the Negotiable Instruments Act, 1881 if the payee re-presents.
RBI's CTS-2010 circular (DPSS.CO.CHD.No./133/04.07.05/2011-12) mandates a 90-day validity window from the cheque date. Manual registers rely on the accountant remembering to check the date column and compute the day count. Instruments dated 91–120 days old regularly enter deposit batches and are rejected by the clearing house, forcing a reversal in the bank reconciliation and distorting the month-end cash position.
A cheque with an empty payee line is effectively a bearer instrument — any holder can present it. Accountants approving instruments for deposit don't always inspect the payee field against the vendor master. Internal controls under the Companies Act, 2013 Section 128 require payment records to identify the beneficiary, and no spreadsheet register enforces this at entry time.
Conditional formatting catches neither the semantic equivalence between "One Lakh Forty Five Thousand Only" and 145000 nor the CTS-2010 stale-date rule in a single formula. The work is done by people, slowly, and exceptions surface only when the bank rejects the instrument — days after the fact, with the reconciliation already closed. An SA 265-driven audit routinely raises a management letter point on payment controls when no systemic validation log exists.
The monthly clerical cost of manually reading, registering, and validating 80–200 cheques at a mid-market entity. Beyond that scale, the error rate on figures-vs-words parity and CTS-2010 staleness rises faster than headcount can compensate — and each return memo costs 2–3 additional banking days in cash flow and an accounting reversal entry. The downstream audit exposure under SA 500 (Audit Evidence) compounds when the register cannot demonstrate which instruments were validated and how.
Cheque issuance and deposit sit inside four distinct regulatory frameworks in India. Each one creates a concrete obligation on the controller — not a best-practice recommendation.
Section 138 makes dishonour of a cheque for insufficiency or mismatch a criminal offence, with imprisonment up to two years or a fine up to twice the cheque amount. The six-month limitation clock starts from the date of the return memo. Catching figures-vs-words mismatches and stale-dated instruments before deposit is the only reliable upstream mitigation — returning a rejected instrument after the bank clearing cycle is not.
RBI's 2012 circular mandates that all presenting banks refuse cheques older than three months from the instrument date. The clearing house operationalises this as a hard stop. Internally, the issuing entity's cheque register must flag stale instruments before they enter the deposit batch — otherwise the clearing rejection forces a reconciliation reversal and distorts the daily cash position reported to treasury.
Section 128 requires companies to maintain books of account that include records of all payments, identifying the beneficiary. A blank-payee cheque in the register creates a gap in the payment audit trail. Statutory auditors sampling the payments working paper under SA 505 (External Confirmations) will flag any register row where the payee is null — and a systemic pattern raises a SA 265 management letter point on payment controls.
SA 330 requires the auditor to test that controls are operating effectively, not merely documented. A cheque-validation control documented in the ICE memo but executed manually on 60% of instruments fails this test. Cadel's register provides a timestamped, per-row validation outcome for every instrument — direct evidence of operating effectiveness that maps onto the auditor's control-testing work programme under SA 330.
Seven deterministic steps from cheque image to validated register entry — in under 10 seconds per instrument. Every step produces a structured, auditable output with no manual key-in.
Accepts cheque images and scanned PDFs through a drop zone, auto-rotates skewed or upside-down scans to the standard landscape orientation, and routes each file into the Cheque document type. Handles multi-page PDFs (one cheque per page) and JPEG image batches without manual sorting.
Extracts cheque_no, payee, amount_figures, amount_words, cheque_date, account_number, ifsc, and a boolean signature_present from each instrument. Fields absent from the physical cheque are recorded as null, not as zero, preventing silent arithmetic errors in downstream calculations.
Parses the amount_words string using the Indian numbering convention — lakh, crore, thousand, hundred — into an integer and compares it byte-for-byte against amount_figures. A mismatch raises a deterministic FAIL under the Figures Match Words rule with both parsed integers exposed in the validation comment so the reviewer sees the exact discrepancy (e.g. 50000 vs 5000).
Computes the difference in days between cheque_date and today's processing date. Raises a FAIL under the Cts 2010 Stale rule when the difference exceeds 90 days, consistent with the RBI circular mandating a three-month validity window. Post-dated cheques (future cheque_date) pass this check — the rule is one-sided — and are tagged separately as PDC instruments.
Enforces a non-empty payee check (Payee Required, FAIL on blank) and an IFSC format check against the standard four-alpha, zero, six-alphanumeric pattern (Ifsc Format, WARNING on anomaly). IFSC anomalies let the cheque proceed but tag the row for manual confirmation before deposit — consistent with the payee-identification requirement under Companies Act Section 128.
Posts each cheque to the register inbox with a three-tier status badge: Clean (all five checks pass), Warning (at least one WARNING-level finding, no FAIL), or Failed (at least one FAIL). Failed instruments route automatically to the exception queue with the specific rule cited — the reviewer sees exactly what broke, not just a red flag.
Produces a structured Excel export of the register with columns for cheque number, date, payee, amount, account number, IFSC, signature status, validation outcome, and exception detail. The column layout maps directly to a Tally Prime Payment Voucher import or a NetSuite vendor-payment record — ready to attach to the month-end payments working paper for statutory audit under SA 500 (Audit Evidence).
A battery of synthetic test scenarios that exercise every failure mode seen in real-world cheque batches. Each produces a deterministic outcome an auditor or controller can verify in seconds.
Four seeded cheque samples — each engineered to exercise a different validation rule. Three clear the register. One goes straight to the exception queue with the exact rule and delta cited.
All five validations pass. Figures 145000 parsed from words "One Lakh Forty Five Thousand Only" — exact match. IFSC ACME0001234 conforms to the four-alpha-zero-six pattern. Signature detected. Instrument proceeds to register with a Clean badge.
A 10x discrepancy — one zero dropped in the words field. Figures Match Words returns FAIL with both integers (50000 vs 5000) in the validation comment. If deposited, this would be returned by the drawee bank and could trigger a Section 138 complaint if re-presented after dishonour.
Cts 2010 Stale returns FAIL with the day-count delta (110 days, exceeds 90) in the comment. Had this cheque entered the clearing batch, it would have been rejected by the clearing house — forcing a reversal in the bank reconciliation and distorting month-end cash.
Payee Required returns FAIL; payee = null is surfaced in the register row so the reviewer sees exactly what is missing. The null value is preserved in the Excel export — it does not default to zero or an empty string, preventing silent mismatches in downstream vendor reconciliation.
A 6–10 hour monthly cheque review collapses to under 15 minutes of reviewer time on the exception queue alone. The four named validation classes — figures parity, CTS-2010 staleness, payee presence, and IFSC format — are applied uniformly to every instrument, not selectively based on what the clerk happened to check carefully that day.
Parsing the Indian-format words string into an integer and comparing it to the figures field catches the class of error that, if deposited and dishonoured, starts a six-month criminal liability clock under Negotiable Instruments Act Section 138. The check runs in milliseconds and costs nothing compared to the cost of a return memo, reversal entry, and legal notice.
The register and its Excel export carry a timestamped validation outcome for every cheque — direct evidence that the payment control is operating effectively under ICAI SA 330. The auditor's SA 505 confirmation sample drops directly into the working paper without manual reconstruction, eliminating the SA 265 management-letter point that manual registers invite.
WARNING-level findings (IFSC anomaly, signature absence) tag the row for manual confirmation without blocking the deposit batch. FAIL-level findings (mismatch, staleness, blank payee) hold the instrument in the exception queue with the specific rule cited. Reviewers see exactly what to fix, not a generic alert — keeping the queue actionable and preventing alert fatigue on the AP desk.
The questions finance controllers and statutory auditors ask most often before deploying cheque scanning automation.
Yes. The CTS-2010 image standard is uniform across all RBI-regulated scheduled commercial banks and cooperative banks, so the extraction model handles cheques from any bank without per-bank configuration. The IFSC validator accepts any code matching the standard four-alpha, zero, six-alphanumeric pattern — Acme Bank, HDFC, SBI, cooperative banks, and RRBs all use the same format mandated by RBI.
The amount_words string is parsed into an integer using the Indian numbering convention — lakh, crore, thousand, hundred — and compared byte-for-byte against amount_figures. A mismatch raises a deterministic FAIL with both parsed integers exposed in the validation comment (e.g. figures = 50000, words parsed = 5000), so the reviewer sees the exact discrepancy rather than a generic "mismatch" flag. The parser handles common variations in phrasing such as "Only", "Rupees", "Rs.", and hyphenated forms like "Forty-Five".
The register supports SA 500 (Audit Evidence) and SA 505 (External Confirmations) when the statutory auditor samples outstanding payments at year-end. Each row carries the validation outcome, timestamp, and exception detail, which is sufficient evidence of the payment control's operating effectiveness under SA 330 (Performing Audit Procedures in Response to Assessed Risks, Para 18–19). The Excel export is the format auditors request for the payments working paper — it requires no further transformation to slot into the audit file.
The Excel export carries cheque number, date, payee, amount, account number, IFSC, signature status, and validation outcome in a column layout that maps directly to a Tally Prime Payment Voucher import or a NetSuite vendor-payment record. Posting is intentionally left to the ledger as a deliberate control boundary — the workflow validates the instrument but does not automatically post until a human approves the register row. This separation satisfies the maker-checker control requirement most internal audit frameworks mandate for payment processing.
Yes. Post-dated cheques (PDCs) pass the CTS-2010 staleness check because the rule is one-sided — instruments older than 90 days fail, future-dated instruments do not. The register tags PDC instruments separately in the status column so they are not accidentally included in the current deposit batch. This is consistent with RBI guidelines on the handling of post-dated cheques collected as security deposits — they should be held in a separate control and presented only on or after the instrument date.
WARNING-level findings — IFSC format anomalies and signature-absence flags — allow the cheque to proceed into the register but tag the row for manual confirmation before the instrument is submitted for clearing. FAIL-level findings — figures-vs-words mismatch, CTS-2010 staleness, and blank payee — hold the instrument in the exception queue until a reviewer either resolves the defect or records an explicit override with a reason. The distinction maps onto the two-tier exception taxonomy most SA 265-driven payment control reviews use: significant deficiency (FAIL) vs. other deficiency (WARNING).
Section 138 liability attaches to dishonoured cheques — where the drawee bank returns the instrument because "the amount of money standing to the credit of the account is insufficient." A figures-vs-words mismatch causes the drawee bank to return the instrument under its internal verification protocol, which can trigger the Section 138 clock if the payee re-presents the cheque and it is again dishonoured. The six-month limitation under Section 138 proviso (c) of the Negotiable Instruments Act, 1881 runs from the date of the return memo. Catching mismatches before deposit is the only reliable upstream mitigation.
The words parser is built for the Indian English numbering convention — lakh, crore, thousand, hundred — as standardised across CTS-2010 instruments printed by scheduled banks. Cheques where the words field is written in a vernacular language (Hindi, Marathi, Gujarati, Bengali) will return the amount_words field as extracted text with a null parsed integer, surfacing the row for manual review rather than raising a false FAIL. This is consistent with the null-rather-than-zero convention used across all fields in the extraction schema — preventing silent arithmetic errors in downstream calculations.
