SA 505 external confirmation extraction + tolerance check + exception routing — balance confirmation letter automation in under 30 seconds per batch.
Manual balance confirmation letter processing breaks at scale. Finance teams managing 50–200 debtors, creditors, and bankers in scope for a year-end audit routinely spend 3–5 working days on an exercise that should take minutes — and the spreadsheet at the end is still error-prone.
Each signed reply arrives as a scanned PDF with no machine-readable structure. A controller opens every file, reads the balance figure, enters it into a master tracker, computes the difference, and sets a status manually. With 80–150 replies arriving over 2–3 weeks, the spreadsheet accumulates formula errors and mismatched PAN references that go undetected until the auditor raises a query under SA 505.
When a counterparty's balance matches but the signatory block is blank, a manual review almost always marks the record as confirmed and moves on. But SA 505 paragraph 7 is explicit: a confirmation signed by an unauthorised or absent signatory does not constitute valid audit evidence. The Partial status is systematically missed in spreadsheet-based workflows, exposing the audit to a qualification risk.
Counterparties that never return a signed confirmation sit silently in the tracker as pending rows. Without a systematic 30-day staleness check aligned to SA 505 paragraph 12, auditors discover non-responses only when they request the confirmation register during fieldwork — triggering emergency follow-up calls and extending the reporting timeline by days.
The confirmation register is a point-in-time snapshot. Auditor requests for an up-to-date count of Agreed, Disagreed, Partial, and No Reply responses arrive when the spreadsheet is mid-update, forcing teams to share inconsistent data. Differences below the materiality threshold also go unclassified because no systematic tolerance check — such as the Rs 100 threshold aligned to Companies Act 2013 Section 143 audit norms — is applied uniformly.
The typical duration of a manual balance confirmation exercise for 100 counterparties at a mid-market company — time spent printing letters, chasing replies, keying balances into spreadsheets, computing differences by formula, and colour-coding exceptions by hand. Each day of delay after the audit fieldwork start date costs the finance team incremental auditor hours billed under Section 143(3) of the Companies Act 2013.
Four overlapping standards govern every balance confirmation exercise in a statutory Indian audit — from the auditor's obligation to control the process, to the company's obligation to cooperate and maintain books under audit scrutiny.
SA 505 requires the statutory auditor to design confirmation requests, dispatch them directly, and evaluate every response including non-replies. Paragraph 7 specifies that a confirmation only constitutes reliable audit evidence if it comes from an authorised signatory — making the signatory-present check not optional but mandatory. Paragraph 12 requires alternative procedures for non-responses received beyond a reasonable time.
Section 143(3)(d) requires the auditor to confirm in their report that they have obtained all information and explanations necessary for the purpose of the audit. An incomplete or unreconciled confirmation register is a direct gap against this obligation and can prompt a qualified opinion if the unconfirmed balance is material — typically ≥ 5% of total assets for mid-market companies under MCA reporting norms.
Every Indian counterparty's GSTIN embeds their PAN under Rule 10 of the CGST Rules. A confirmation letter where the PAN and GSTIN are inconsistent (characters 3–12 of the GSTIN should match the PAN) may indicate a keying error or a counterparty identity mismatch — a material fact for auditors assessing trade receivable authenticity and for companies cross-referencing against GSTR-2B reconciliations.
ISA 505 paragraph 13 (the international equivalent of SA 505) requires the auditor to investigate any exceptions that indicate a possible misstatement. A disagreed balance — where the counterparty's books show a different figure from the company's ledger — is not just a documentation item; it is a risk indicator that must be followed up with additional substantive procedures, not simply noted and filed. SA 505 carries the same obligation under paragraph 16.
Seven deterministic passes from scanned confirmation reply to audit-ready working paper — in under 30 seconds per batch regardless of how many replies arrive simultaneously.
Accepts bulk PDF uploads of signed confirmation replies and classifies each file as a Confirmation document automatically, without requiring the controller to tag document types manually. Mixed batches containing Debtor, Creditor, and Banker replies in the same upload are processed in a single pass.
For each reply, extracts eleven structured fields: counterparty_name, counterparty_pan, counterparty_gstin, party_type, request_date, confirmation_date, balance_as_per_party, balance_as_per_books, currency, signatory_name, and signatory_designation — the complete SA 505 evidence set.
Computes the absolute difference between balance_as_per_party and balance_as_per_books and applies a configurable Rs 100 tolerance threshold. Differences within tolerance with a valid signatory and confirmation date are classified Agreed; differences exceeding the threshold are classified Disagreed regardless of other fields.
Assigns one of four statuses to every reply: Agreed (difference ≤ Rs 100, signatory present, confirmation date valid), Disagreed (difference > Rs 100), Partial (balance matches but signatory or confirmation date absent — per SA 505 paragraph 7), or No Reply (no confirmation date and request date > 30 days old per SA 505 paragraph 12).
Runs five deterministic checks on every extracted record: Balance Match Within Tolerance (FAIL), Confirmation Date Required (FAIL), Signatory Required (FAIL), PAN Structure validation against the 5-letter–4-digit–1-letter format (WARNING), and Party Type Valid against the Debtor / Creditor / Banker enum (WARNING). Any FAIL-severity result routes the record to the exception queue.
Builds and updates a confirmation register showing every counterparty, their extracted fields, computed difference, and current status — updated live as additional replies arrive. The register is the primary working view during the 2–3 week confirmation window, giving the finance team and the auditor a single point of truth instead of a shared spreadsheet with competing versions.
Exports a structured Excel file containing one row per counterparty with all extracted fields, computed difference, status classification, failing validation messages, and a summary count by status category. The export is formatted to slot directly into the statutory audit file as the SA 505 confirmation register, eliminating manual assembly from a spreadsheet tracker.
A battery of synthetic test scenarios that exercises every failure mode seen in real-world confirmation data. Each scenario produces a deterministic outcome an auditor or controller can verify in seconds.
Four seeded confirmation replies — one for each status class. Three extract and classify cleanly. One surfaces three simultaneous FAIL checks, proving that a stale no-reply cannot hide in the register undetected.
Both balances at Rs 18,75,000. Confirmation date 3 days after request. Signatory Acme Applicant (CFO) present. All five validation checks pass — status Agreed, green badge in inbox.
Rs 45,000 gap exceeds the Rs 100 tolerance. Balance Match Within Tolerance FAIL fires; record routed to exception queue with reconciling item flagged on audit working paper for follow-up per SA 505 paragraph 16.
Balances agree at Rs 42,50,000, but signatory name and designation are blank. Signatory Required FAIL under SA 505 paragraph 7; status Partial; excluded from Agreed count. This is the case most likely to be misclassified manually as confirmed — the workflow catches it deterministically.
Three FAIL checks fire simultaneously: balance difference of Rs 6,42,500, no confirmation date (45-day stale > 30-day threshold per SA 505 paragraph 12), and no signatory. A spreadsheet review would not surface this until the auditor specifically asked for a breakdown by status.
For a finance team managing 100 counterparty confirmations per audit cycle, this balance confirmation automation replaces 3–5 working days of manual data entry, formula checking, and status tracking with a process that completes in under 30 seconds of active effort per batch — and catches exception classes that a manual reviewer almost never surfaces consistently.
The Signatory Required check fires on every record where signatory name or designation is absent — regardless of whether the balance agrees. In a manual spreadsheet review, a balance-matched record is almost invariably marked confirmed and filed. The workflow's status logic is the only reliable way to enforce SA 505 paragraph 7's authorised-signatory requirement at scale without relying on reviewer judgment.
The Excel export is structured to slot directly into the statutory audit file as the SA 505 confirmation register: one row per counterparty, all extracted fields, computed difference, status classification, and pre-populated remarks carrying the failing validation messages. The auditor receives a traceable, field-level record linking each row back to the source PDF — satisfying ICAI SA 230 (Audit Documentation) requirements without the finance team maintaining a parallel manual register.
The live confirmation register replaces the shared-spreadsheet model where multiple controllers update different rows and the auditor receives a point-in-time snapshot that may already be stale. Every reply uploaded during the 2–3 week window updates the register immediately, giving both the finance team and the statutory auditor a consistent, real-time view of how many counterparties have Agreed, Disagreed, are Partial, or have not replied — with no version-control overhead.
The questions auditors, controllers, and finance managers ask most often before deploying balance confirmation automation.
The workflow is built around ICAI SA 505 — External Confirmations, which requires the statutory auditor to design confirmation requests, control the process, and evaluate responses including non-replies and disagreements. Cadel enforces the three mandatory fields SA 505 paragraph 7 specifies — confirmation date, authorised signatory name, and signatory designation — and auto-classifies each response as Agreed, Disagreed, Partial, or No Reply so the auditor's working paper reflects all four response states required for the completion memo. The 30-day staleness threshold for No Reply is drawn directly from SA 505 paragraph 12.
The default tolerance is Rs 100: any absolute difference between the balance as per the counterparty's books and the balance as per Acme's audit schedule that exceeds Rs 100 triggers a Disagreed classification and a FAIL on the Balance Match Within Tolerance check. Controllers can adjust this threshold in the workflow configuration to match their materiality level or the tolerance agreed with the statutory auditor for a given engagement. For high-value banking confirmations, a Rs 0 tolerance is common; for trade debtors with rounding differences across accounting systems, Rs 100 or Rs 500 is typical.
If the gap between the request_date extracted from the confirmation letter and the system date exceeds 30 days and no confirmation_date is present, the record is automatically classified as No Reply and the Confirmation Date Required check fires as a FAIL. This mirrors SA 505 paragraph 12, which requires the auditor to perform alternative procedures when responses are not received within a reasonable time. The exception queue surfaces all stale no-reply records for immediate follow-up, giving the finance team a clear action list without needing to sort the confirmation register manually.
PAN is validated against the standard Indian format — five uppercase letters, four digits, one uppercase letter — per Rule 10 of the CGST Rules 2017. GSTIN is checked for the two-digit state code prefix and the embedded PAN structure (characters 3–12 must match the PAN). A malformed PAN triggers a WARNING (not a hard FAIL) so extraction is not blocked, but the record is flagged in the confirmation register. Auditors use these warnings to verify counterparty identity before accepting the confirmation as third-party evidence under SA 505, and to cross-check against GSTR-2B if the counterparty is also a GST-registered vendor.
The Excel export produced by the workflow contains one row per counterparty with columns for counterparty name, PAN, GSTIN, party type, request date, confirmation date, balance as per party, balance as per books, computed difference, status classification, signatory name, signatory designation, and a remarks column pre-populated with the failing validation messages for each record. A summary tab provides a count of Agreed, Disagreed, Partial, and No Reply responses. This format is designed to slot directly into the statutory audit file as the SA 505 confirmation register, reducing manual assembly from several hours to a single export step and satisfying the documentation requirements of ICAI SA 230.
The currency field is extracted from each confirmation letter and stored alongside the balance fields, so USD, EUR, or other currency confirmations from foreign subsidiaries or overseas vendors can be processed in the same inbox. The balance difference check is applied within the stated currency; cross-currency conversion is not performed automatically and should be handled in the audit schedule before uploading. PAN and GSTIN validations are India-specific and fire as warnings rather than hard failures for non-Indian counterparties, so the workflow does not block processing of international replies. For entities reporting under IFRS or subject to foreign jurisdiction audit standards, the core extraction-and-tolerance logic applies unchanged.
ICAI SA 505 is substantially converged with ISA 505 issued by the IAASB: both standards require auditor control of the confirmation dispatch and receipt process, evaluation of non-responses, and documentation of results including exceptions. The key India-specific addition is PAN and GSTIN identity verification for Indian counterparties, which has no direct ISA 505 equivalent. For entities reporting under Ind AS (which converges with IFRS) or subsidiaries of companies subject to PCAOB AS 2310 (US listed entities), the workflow's core logic — balance extraction, tolerance check, signatory validation — applies unchanged; only the identity-field validation rules need jurisdiction-specific configuration in the workflow settings.
Yes. The workflow accepts a mixed batch of signed confirmation replies from all three party types — Debtors, Creditors, and Bankers — in a single upload. Each reply is classified by party type automatically based on the extracted party_type field and counted separately in the confirmation register. The exception queue can be filtered by party type, so auditors can triage Banker non-replies (where alternative procedures such as obtaining an independent bank statement are more constrained) separately from trade-debtor or trade-creditor disagreements. The Excel working paper export includes a breakdown by party type for the summary tab.
