Product
One engagement file, from raw data to signed working paper.
Lekhya is not a collection of tools bolted together. Data enters once, testing runs across it, evidence stays linked to it, and the working papers come out of the same file the testing happened in.
Illustrative product interface showing an audit engagement with sample data
Areas
Revenue
2,417 transactions tested8 exceptionsPotential revenue cut-off issue
₹18,40,000
- Invoice date
- 29 Mar 2026
- Revenue entry
- 29 Mar 2026
- Dispatch date
- 03 Apr 2026
Goods were dispatched after the year end. Revenue appears to have been recognised in FY 2025–26 on an invoice raised before dispatch. Confirm the terms of transfer of control before concluding.
Evidence
- Invoice INV-2026-1184Page 1
- Dispatch document DC-4471Page 1
- General LedgerRow 18,921
Drafted · unreviewed · awaiting a named auditor
Illustrative interface with sample data for a fictional client.
The engagement spine
Every module sits on the same four stages.
A module is not a separate product. It is a set of procedures that runs on data already ingested, producing evidence already linked and papers already in your format.
01 · Module
Purchase & AP testing
The chain runs purchase order → goods receipt → invoice → purchase register → general ledger → payment. Lekhya matches every link across the full population and names what breaks.
When the data is imperfect
Most mid-market clients do not maintain goods receipt notes reliably. When a GRN does not exist, Lekhya does not fail — it raises the absence as a finding in its own right and matches on the documents that do exist.
Procedures
- Three-way matching across order, goods receipt and invoice
- Duplicate invoice detection across vendor, amount and date variants
- Missing goods receipt or missing approval
- Price and quantity variance against the order
- Cut-off testing either side of the year end
- Payments without a matching invoice
02 · Module
GSTR-2B reconciliation
GSTR-2B against the purchase register against the general ledger, monthly. The differences are categorised rather than handed over as one long list.
When the data is imperfect
The reconciliation runs monthly, which means by the time the statutory audit starts the year's differences are already identified and explained rather than discovered in October.
Procedures
- Timing differences between supplier filing and your client's books
- Credit claimed against invoices absent from 2B
- Ineligible credit under section 17(5)
- Rate mismatches between invoice and register
- Credit recorded against an incorrect GSTIN
- Reconciliation carried into the statutory audit file
03 · Module
Revenue & cut-off testing
Invoice date, revenue posting date and dispatch date compared for every transaction near the year end — the test that most often produces a real finding.
When the data is imperfect
Cut-off is the area where a reviewer most wants to see the underlying document. Every cut-off exception opens directly onto the dispatch note with the date highlighted.
Procedures
- Dispatch after year end against revenue recognised before it
- Credit notes issued after the balance sheet date against prior-period invoices
- Unusual concentration of invoicing in the final days of the year
- Revenue postings without a corresponding dispatch document
- Round-sum invoices and just-below-threshold values
04 · Module
Evidence management
Documents arrive by upload or from the client portal, are classified, and have their fields extracted. Each figure keeps a link to the page it came from.
When the data is imperfect
Where a document is a poor scan and a field cannot be read with confidence, Lekhya marks it for review rather than guessing. The gap is displayed, never silently filled.
Procedures
- Automatic classification of invoices, goods receipts, dispatch notes and statements
- Field extraction from scanned and digital documents
- Missing-document detection against the expected population
- Evidence links scoped to a user's existing access
- Links preserved as page references on export
05 · Module
Working papers & review
Each procedure produces a working paper in your firm's format, with tickmarks, cross-references and the population tested — assembled as the work is done.
When the data is imperfect
The audit trail is designed to be handed to a peer reviewer without preparation. Every action carries a user, a timestamp and the value it replaced.
Procedures
- Working papers generated from the procedures actually run
- Preparer, reviewer and partner sign-off against named users
- Review notes raised, answered and cleared in place
- Full audit trail with prior values, exportable with the file
- Prior-year rollforward with methodology versioning
Boundaries
What Lekhya does not do.
The most useful thing a vendor in this category can publish. If a capability is not listed on this site, we do not have it.
It does not form an opinion
No conclusion, no opinion and no report is produced without an auditor writing it and signing it.
It does not decide materiality
Materiality and performance materiality are set by the engagement team. Lekhya applies what you set.
It does not replace judgment procedures
Estimates, going concern, related parties and management representations remain entirely yours.
It does not compute with a language model
Totals, variances and reconciliations are deterministic. A model reads documents; it never does the arithmetic.
Where the data comes from
Built for the files your clients actually keep.
Tally
Company file connection or XML / Excel export, with ledger mapping you review once.
GST portal
GSTR-2B and GSTR-1 data pulled for the period under audit.
Bank statements
PDF and Excel statements from major Indian banks, parsed to transactions.
Documents
Invoices, goods receipts and dispatch notes — scanned or digital, uploaded or collected.
See it run on an engagement you already know.
The fastest way to judge this is to point it at a completed prior-year audit and compare what it finds against what your team found.