Nevados: A Platform That Builds Audit Workpapers Straight From the Trial Balance

Client

Nevados is an independent audit firm licensed by Turkey's Public Oversight Authority and an independent member of Daxin Global. Its users are auditors and audit team managers.

Together we built a platform that produces audit workpapers automatically from trial balance and general ledger files. The interface is entirely in Turkish, and it is the most data-intensive of the work we do on the Finance and Fintech side.

Challenge

In independent audit, the work starts with this scene: to prepare the file for a new client, the auditor opens the previous client's Excel workbook and clicks "save as".

This is not carelessness, it is necessity. The workpaper set is the audit file itself. Together with its formulas, conditional formatting, hidden sheets and macros, it is the firm's own standard. It cannot be produced from scratch, because whatever gets produced is no longer that firm's paper.

Everything after that was manual:

Data was carried across one cell at a time. Account balances from the trial balance and entries from the ledger were copied into the relevant paper.

Every accounting system speaks differently. The same trial balance arrived with different column names, different account code notations and different sheet layouts. The auditor solved the mapping again for every file.

Evidence was read by hand. Bank confirmations, statements and invoices arrive as scanned PDFs. The auditor opened the file, read the figure, wrote it onto the paper and typed the file reference in by hand.

Comparative periods were assembled manually. The current year, the prior year and the year before that were pulled together from separate files.

The real risk this process creates is not slowness, it is silence. A copied template still carries the previous audit's figures in its cells; if they are not cleaned out, they get published under the new client's name. When a comparative period is missing, copying the current year is the easiest route and the most dangerous one in audit terms. None of this raises an error on screen.

Why it is hard to automate

One sentence separates this project from ordinary reporting work: regenerating the Excel file is not an option, filling it in place is mandatory.

Telling a library to write a fresh workbook from the data would have been the fastest route, and the resulting file would have been useless. A workpaper is audit evidence. It goes through quality control and it gets archived. Its formatting, its formulas and its macros matter as much as its numbers.

So the platform fills the template in place, inside the file format's own internal structure. The rules that follow from this sit at the centre of the architecture:

The Cell-Type Mirror Principle. A formula cell stays a formula, a literal stays a literal. Writing a value into a formula cell breaks the workpaper silently, so this is verified automatically after every render.

The previous client's data never reaches the output. Figures inherited from templates are cleaned out, and a test guarantees it.

A missing period is never invented. On first-year audits, when there is no comparative period, the gap is not filled. It surfaces to the auditor as a warning.

Macro-enabled files survive intact. The macro project is preserved at byte level and the file comes out with its macros working.

There is also a trap specific to Turkish: unless the uppercase and lowercase conversion of İ and ı is handled separately, account name matches drift silently. Each rule of this kind was added to the codebase's written memory the first time it was encountered.

Solution

The pipeline runs one way: Excel goes in, the database holds the canonical data, Excel comes out.

Import and normalisation

The auditor uploads the trial balance and ledger files. The system profiles the file, recognises which accounting system produced it, and reduces the account codes to a single canonical form.

It then proposes a column mapping, and no data is loaded until the auditor approves it. On upload, debit and credit totals are compared; an unbalanced trial balance does not pass silently.

After this point the file is never read again. MongoDB is the single source of truth, with monetary fields held in a type that does not lose decimals.

Mapping and reconciliation

Accounts are mapped to the standard chart of accounts and classified. The trial balance and the ledger are compared account by account and the differences are shown to the auditor. The comparative period chain is built automatically.

The evidence reading layer

The auditor uploads scanned evidence to the relevant section. A language model running on the firm's own internal network reads the document and extracts structured data. The extracted rows are attached to the correct line of the workpaper by amount, account code or account name, and the source file and page number are stamped on as the reference.

Two design decisions define this entire layer. First, the document never goes to an outside service; the model runs inside the firm's own network. Second, no extraction is ever applied automatically; the auditor sees it, approves it, and only then does it reach the paper. This is the concrete version of the position we take on AI integration work: the model proposes, the human decides.

Rendering and delivery

Rendering runs in a background queue, so the auditor is not left waiting at the screen. The queue has two channels, which keeps short jobs like imports from being blocked behind long ones like rendering and document reading.

The output is delivered as an archive laid out in the audit firm's own folder structure, with evidence files sitting under the section they belong to.

The audit's own calculations

The platform does more than move data. It also runs the audit's own numbers: lease calculations, internal rate of return, loan amortisation schedules, period-end valuation using central bank rates, and reference interest rates.

How we built it

The AI in this section is a separate matter from the evidence reading layer inside the product. That one is a feature the client uses; this is about how the project itself was built.

We ran the project with an AI-assisted development workflow. The distinguishing part was not "getting an AI to write code". It was turning the domain rules into a written constitution.

We kept a rules file in the repository: boundaries between modules, the principle that the template is untouchable, the Cell-Type Mirror Principle, never filling a missing period, never letting the previous client's data leak. What these rules have in common is that breaking them raises no error. They just produce quietly wrong output.

Every bug that got fixed was written back into that file as a rule so it could not recur. Alongside it we kept a persistent notes directory, each note recording a single fact. A new session starts from that accumulated context rather than from nothing.

The measurable side: roughly 85,000 lines of production code in that time, across three languages and three runtimes in one repository. The real gain was not speed, though. In a project like this the dangerous failures are invisible on screen; the interface says "applied" while the workpaper stays empty. The gain was catching those silent failures and turning each one into a rule.

Result

The project started in early May 2026 and went live on 10 August 2026, roughly fourteen weeks.

Today every audit section is produced automatically: 76 template files and 510 sheets, filled without losing formatting or formulas. Three comparative periods are built automatically. Evidence files are attached to the workpaper with a source and page reference.

On the quality side there are 323 automated tests, and some of them are not conventional unit tests but checks on domain rules: a formula cell must stay a formula, the previous client's figures must not appear in the output. Module boundaries are enforced by tests at build time as well.

One measured performance example: a rendering pass went from 14.9 seconds to 1.1 seconds, and the output stayed byte-for-byte identical. In audit work, "faster but slightly different" is not an acceptable result.

Technology

.NET · MongoDB · Python · Next.js · React · TypeScript · shadcn/ui · Tailwind CSS · self-hosted LLM

The architecture is a modular monolith: business modules talk only through interfaces, and those boundaries are protected by architecture tests. On the authentication side there is multi-factor verification and a session model in which the browser never sees a raw token.

Building something similar?

If you have a template set that gets filled in by hand, in audit, accountancy or reporting, the hard part is not the automation. It is that the output still has to be your document at the end of it. On the custom software development side we can work through this kind of data-heavy, rule-bound problem with you.