Skip to content

Part 1: The audit team's season

From client ledger to evidence pack without leaving the platform. Ten steps, most of them minutes.

Step 1: Set up the client and the engagement

Create the audited entity under Clients — name, registration number (KvK or IČO), country — and invite the client's signer from the same card. Then create the engagement: client × fiscal period, currency, materiality and performance materiality. Performance materiality is not decoration — it is the tolerable misstatement the ISA 530 sampling interval is derived from later.

The Clients screen: five fictional client companies with their registration numbers, country and status; the form to add a client; and the signers panel for Alfa Productie B.V., listing its active signer and the form to invite another by e-mail.
The audited entity and the director who signs for it, on one card. The signer is invited by e-mail and creates their own account; nobody at the audit firm signs on the client's behalf.

Step 2: Import the client ledger — any Dutch, Czech or English export

Upload CSV or XLSX from Exact Online, AFAS, Twinfield, Pohoda, Money S3, Helios or SAP-style exports. The two-step import previews the file, suggests a column mapping from Dutch, Czech and English headers, and handles "1 234,56", "1.234,56", "(500)", dd-mm-yyyy dates and mixed code pages — Windows-1250 and Windows-1252 are told apart by scoring, not guessed. Rows the parser cannot read are rejected with the reason and the raw cell, never silently skipped. Re-importing never destroys evidence: prior rows are superseded, not deleted, and the supersession is recorded on the audit trail.

Import kinds: AR balances · AP balances · Bank balances · Open items · Subsequent receipts · Subsequent payments.

Step 3: Generate an ISA 530 sample the partner can defend

A bank population is not sampled at all: every account is confirmed, overdrafts and zero balances included — a census, because an account the ledger records as an overdraft is a liability the bank confirms, not a stratum to be sampled out. Receivables, payables and general balances are sampled as follows.

One click runs Monetary Unit Sampling over positive balances — systematic PPS, top stratum always selected. The interval is performance materiality divided by the reliability factor at the confidence level the auditor states, 95% by default: a performance materiality of 1,200,000 gives an interval of 400,534.05. An auditor who plans the interval another way states it, and the basis, at approval. Explainable risk rules are added on top: round amounts, duplicate counterparty-amount pairs, off-hours postings. Every selected item stores a plain-language reason for the working paper, and the random seed is stored, so the exact sample is re-derivable at review. Curate items, then a partner approves — which locks the roster.

At a glance

Bank balances
A census — every account, overdrafts and zero balances included.
Other balances
Monetary Unit Sampling, the interval performance materiality over the reliability factor at 95% confidence by default.
Every selected item
A plain-language reason for the working paper; the random seed stored.
Approval
By a partner, which locks the roster.
An engagement's client data imports (an AR balance ledger of nine rows and a subsequent-receipts file, each with its row and skipped counts) beside its approved ISA 530 sample: monetary-unit sampling with risk rules, a sampling interval derived from performance materiality over the reliability factor for 95% confidence, the random seed, the population and the selection, drawn by the team and approved by the partner; the provisional evaluation of the sample, with the items not yet concluded counted at full book value; and the roster of the seven selected items, each with the reason it was selected (top stratum, a round-amount risk rule, or a systematic hit at a stated monetary unit).
One client-period: the imported ledger and the ISA 530 sample drawn from it, with its interval, assurance basis, stored seed and a stated reason for every selected item. The team draws the sample; the partner approves it.

Step 4: Build the batch and assign responders from a verified directory

Create a batch from the approved sample — one confirmation per included item, carrying the ledger balance — or add confirmations by hand for any of the eight kinds the platform sends: bank balances, bank relationships, receivables, payables, legal, insurance, leases, or a general balance — with the batch's own as-of date, deadline, reminder policy and letter language: Dutch, English or Czech, end to end.

A legal request is an ISA 501 inquiry to the company's lawyers — litigation, claims and assessments, unbilled fees — and it carries no balance anywhere: the letter asks its questions, the row holds no figure, and the portal offers none to confirm. A bank relationship enquiry is the same shape at a bank: one request per bank rather than per account, asking for every account held, the loans and credit facilities with their limits and terms, the guarantees and sureties given or received, the security and pledges and over which assets, and who may sign — also with no balance anywhere. An insurance confirmation asks an insurer the same way: the policies in force at the as-of date, the sums insured and limits and deductibles under them, the claims notified, and the premiums outstanding — the premium is stated by the insurer and read against the client's records rather than reconciled, so this request too prints no balance and offers none to confirm. A lease confirmation asks a lessor the same way: every lease and rental agreement in force with its asset, its dates and its remaining term, the amount outstanding on the lessor's own basis with the payment schedule, the payments received in the period, and the residual value guarantees, options and security. Its amount is material and the client's ledger holds a relative of it — a lease liability — and the two are still not compared, because they are measured on different bases: the lessor holds the remaining rentals receivable and the client an IFRS 16 present value or, for an operating lease under Dutch or Czech GAAP, nothing at all. The figure is stated, read against the lease schedule by a person, and this request too prints no balance and offers none to confirm.

Every responder contact carries provenance (auditor-entered, client-provided, published channel, prior response, AI-suggested) and a verification tier: unverified → MX-checked (an automated pre-check on the e-mail domain, explicitly not the ISA 505 control) → auditor-verified → network-verified. Dispatch is refused below auditor-verified unless an override reason is recorded, and it lands on the audit trail — the ISA 505 / AS 2310 control, applied by the platform rather than written in a policy PDF. A curated directory — Dutch banks, and Czech banks and insurers — is shared with every firm; each entry's legal name and registration number is verified against the public register (DNB, ARES), with the institution's published confirmation channel cited where one was found, and role addresses require a cited published source. AI can suggest published channels, but suggestions are never used automatically — an auditor must verify first.

The responder directory: each counterparty organization with its contact address, where the address came from (a client-provided listing or a published channel) and its verification tier (network-verified, auditor-verified or MX-checked), with the note recorded for each verification.
Every contact carries its provenance and a verification tier. An MX check is shown as what it is, an automated pre-check on the e-mail domain, and is not treated as verification.

Step 5: Send the client authorization for signature

From the batch, Send for signature: the platform generates the information-release letter listing every counterparty and e-mails the client's signer a secure signing link — name, e-mail, title, one click. Until it is signed, not one confirmation in the batch can be dispatched.

The client's ten minutes

Step 6: Dispatch — verified, attributable, never undoable

Dispatch authorized confirmations e-mails each assigned responder a covering message carrying the secure portal link and a unique reply-to intake address, with the request letter and the signed authorization attached. The letter itself carries the reference and a QR code that opens the same portal; it prints neither the link nor the intake address, because the letter is the artefact that gets filed, photocopied and forwarded onward. Contacts on paper-only workflows get a print-ready letter that still carries the QR, so even a posted letter can be answered digitally.

Every letter and every e-mail is the firm's own business document, not a vendor's: it carries the firm's registered name, seat and registration number — and its register entry and audit licence where the firm has recorded them — labelled the way the firm's own jurisdiction labels them, and the request comes from the firm. Dispatch is blocked until the seat, the registration number and a phone and mailbox a recipient can verify the request with are all on record, because every letter must name the auditor it comes from. The result reports exactly what was sent and what was skipped, and why.

At a glance

By e-mail
A covering message with the portal link and a unique reply-to address.
On paper
A print-ready letter that still carries the QR code to the portal.
Enclosed
The request letter and the signed authorization.
Refused
A contact below auditor-verified with no recorded override reason.
Undo
None. The result states what was sent, what was skipped and why.
A batch's confirmations, two of which have no responder yet, and the responder panel for one of them: its only contact is MX-checked, not verified, so the Assign button stays disabled until an override reason of at least ten characters is written, and the reason is recorded on the audit trail.
The ISA 505 control over the request, applied by the platform: a letter to a contact nobody has verified needs a stated reason, and the reason goes on the record.

Step 7: Track the season from the status funnel

Batch view shows response rate, overdue count and median days outstanding over a colour-coded funnel of the 16 tracked states this batch is actually in. Bounces surface automatically on the affected row. The reminder policy is set per batch by the audit team — which days after dispatch a reminder goes out, when a silent counterparty is marked unresponsive, and whether automated chasing runs at all. The defaults are deliberately patient — a reminder at day 14 and 28, unresponsive at day 45 — and responders who work through their own portal or on paper are never chased by automated e-mail. A counterparty is certified unresponsive only after the chase has run, and never before the date the letter itself gave it to reply — the verdict cannot precede the request.

A receivables confirmation batch for the fictional Dutch client Alfa Productie B.V. as at 31 July 2026, with its letters in Dutch: tiles for seven confirmations, a 60% response rate over five delivered, one awaiting response and 31 median days outstanding; the status funnel; a notice that two confirmations have no responder; and the confirmation rows with balance, responder contact and tier, dispatch and status.
A batch as the team tracks it: the counts, the status funnel, and every confirmation with its contact, its dispatch and reminders, and where it stands. An item that cannot be sent says why.

Step 8: Review what the AI could not prove

Responses run through OCR, extraction constrained to a fixed set of fields, and a verbatim verifier: a number "found" must literally appear in the document text, and validators check currency, as-of date and line-item arithmetic. Only a full validator pass with an exact ledger match, from a sender the request was actually addressed to, auto-accepts. Everything else lands here — source document beside the extracted-versus-ledger comparison — for Accept as extracted, Accept with corrections or Reject. A decision is taken once: a second decision on the same extraction is refused, so two reviewers cannot double-process it. There is no synthetic confidence percentage anywhere: the only confidence shown is the OCR engine's own per-field measurement, labelled as such, and no decision keys on it.

At a glance

Accepted unattended
An exact ledger match, with the responder's currency stated and no deterministic check failing, from a sender the request was addressed to.
Everything else
A person, with the source document beside the extracted-versus-ledger comparison.
The decision
Accept as extracted, accept with corrections, or reject — taken once.

Step 9: Reconcile, explain variances, close non-responders

Reconciliation is deterministic first — exact, within-tolerance, currency-mismatch — with semantic name matching (legal suffixes stripped, similarity scored) when the responder states a different name. For variances, the platform scans open items and subsequent receipts for classic in-transit and timing candidates and drafts an explanation the auditor must rewrite or confirm — labelled AI draft — not audit evidence until you confirm or rewrite it.

A receivable or a payable that goes unanswered gets subsequent receipts or subsequent payments matched by the platform, with the coverage achieved and the amount still unsupported both stated; every other instrument gets the procedures the standard expects named, for the auditor to perform and attach — and a conclusion the platform refuses to write at all.

At a glance

Matching
Deterministic first: exact, within tolerance, currency mismatch.
A difference
Open items and subsequent receipts scanned for in-transit and timing candidates.
A drafted explanation
Labelled a draft, and not audit evidence until the auditor confirms or rewrites it.
No answer
Receipts or payments matched for receivables and payables; every other instrument is the auditor's to evidence, and every conclusion the auditor's to write.
The reconciliations list narrowed to one closed engagement of the fictional Dutch firm, the group reporting audit of Phi Installatietechniek B.V.: each confirmed balance beside the ledger balance and the difference, with match and status (an exception with its note on file, a variance explained with the finalized explanation and two exact matches verified, each signed off), and below it the alternative procedures for the non-responder, with 100% of its balance matched to subsequent receipts, approved and signed off.
Ledger beside confirmed beside the difference, each row with its status and, where a person concluded, their words. A non-responder goes to alternative procedures, with the coverage the receipts achieve stated.

Step 10: Working papers and the evidence pack

Per-confirmation working papers (PDF and XLSX) are regenerated from the event log on every fetch — a stale copy is never served. Batch lead schedules summarize per-books, confirmed, difference and status per row. At close-out, Export evidence pack (ZIP) exports one ZIP: manifest, a fresh verification verdict for the audit trail, a provenance log for every extracted figure, signed authorizations and certificates, dispatch letters, response documents, and all working papers — with the engagement's materiality, performance materiality and each batch's ISA 530 sampling basis stated at the top of it, so a regulator reads the basis of the selection before the selection — and it declares anything it could not include rather than asserting completeness. Designed to ISA 505 / AS 2310 documentation requirements.

Every section of the paper, and what a reviewer receives

At a glance

Working paper
One per confirmation, as PDF and as a spreadsheet (XLSX).
Lead schedule
Per books, confirmed, difference and status, row by row.
Evidence pack
One ZIP, materiality and each batch's ISA 530 basis stated at the top of it.
What is missing
Declared by name, rather than completeness asserted.
Page 2 of a bilingual Dutch and English confirmation working paper: section 2, the response received (when, from whom, the response mode and how the source of the reply was verified); and section 3, extraction and verification (the method, the status, the confirmed balance, the responder's note and the reviewer's reading of it, and the table of checks with their results).
One sheet of a confirmation working paper, in both languages: who answered, how the source of the reply was verified, and the checks run on it.

Part 2: The client's ten minutes

The authorization is the legal hinge of the whole season. Confirmatica makes it a single-purpose link, not a vendor envelope.

Step 1: The invitation

The signer receives a unique signing link by e-mail — no account, no download. The link is single-purpose and expires after 30 days.

Step 2: Read the actual document

The consent letter renders inline as a PDF — every counterparty listed — with its SHA-256 digest printed on the page. The signer's own language leads, with English printed beside it wherever the two differ, because a secrecy release gets filed and forwarded to people who do not read it; an English letter is simply English. What is signed is exactly what the auditor sends, and both sides can prove it.

At a glance

On the page
The authorization itself, every counterparty listed, with its digest printed on the page.
Languages
Dutch, English or Czech — the signer's own leading, English beside it where the two differ.
The choices
Sign with a one-time code sent to the mailbox, or decline with a reason.
The client's signing page in Dutch: the Dutch-led authorization letter, with English beside it, shown inline with the parties it covers and its SHA-256 digest, the signer's details, the one-time code sent to the signer's e-mail with a resend counter, and an option to decline, under the language switch (NL, EN, CS) with Dutch selected.
The director reads the document they are asked to sign, proves control of their mailbox with a one-time code, and signs or declines, in Dutch, English or Czech.

Step 3: Proving the signer is the signer

Send verification code e-mails a 6-digit code to the signer — proof that the person signing holds the mailbox the auditor wrote to, valid for ten minutes. Every step is recorded as evidence of the signature: sent, viewed, code verified, signed, each with the time it happened.

Step 4: Sign — or decline with a reason

Sign the authorization adds a signature certificate page to the signed document and moves every awaiting confirmation to authorized; the audit team is notified. Decline to sign is first-class: it requires a reason, returns the batch to draft, and notifies the audit team — nothing proceeds on silence. The signature is an electronic signature with a documented evidence trail: the signer's possession of the e-mailed link and a one-time code to their mailbox, the time, the address and the document digest recorded on a certificate page — deliberately not a qualified signature, and with no per-envelope vendor cost.

A signed authorization and its signature certificate, numbered page 1 of 2 and page 2 of 2: the Dutch-led authorization for Beta Logistiek B.V. listing the four counterparties it covers, and the certificate recording the document's SHA-256 digest, the signer, the moment of signing and how the signer's mailbox was verified with a one-time code.
What the signature leaves in the file: the signed document, and a certificate stating who signed, when, and how their mailbox was verified.

Part 3: The responder's two minutes

Response rate is won by removing friction. A responder never creates an account, never installs anything, and never has to be told twice how to answer.

Step 1: One letter, two reply channels

The request arrives by e-mail, carrying the secure portal link and a unique reply-to address. The letter travels with it — attached, or printed and posted — and carries a reference number and a QR code that opens the same portal; the link is never set in readable type on it. Answer through the portal, or reply to the e-mail; the paper letter's QR code opens that same portal. Both channels end in the same evidence store. Banks that run their own confirmation portals get a workflow type that respects their process and never chases them with automated reminders.

A reply that reaches the firm another way — by post, by fax, in the firm's own mailbox, or downloaded from a bank's own confirmation portal — is filed by the auditor onto the confirmation with a statement of which route it came by, the day the firm received it and who received it. That statement is the document's provenance, and it is printed wherever a reviewer weighs the document.

The first two pages of the firm's file copy of a bilingual Dutch and English confirmation request to a fictional Dutch customer, marked at the top that the response code is not reproduced: the reference, as-of date and response deadline, the account relationship, the balance per client records, the ways to answer (online with the code on the counterparty's own letter, by e-mail or by post) and the firm's contact details.
The firm's copy of the letter the counterparty receives, in its language beside English: what is asked, by when, and how to answer. The response code is printed only on the letter that is sent; the firm's copy says so at the top.

Step 2: The portal: confirm, upload, type, or decline

Four tiles: Confirm as stated (one click, name recorded), Upload our statement (PDF, image, spreadsheet, Word, text or CSV, up to 25 MB), Type the balance with discrepancy notes, or We cannot confirm — a structured refusal with a reason code, recorded as a refusal rather than as silence (ISA 505), which stops the reminders and routes the item to alternative procedures. Dutch, English and Czech, auto-detected from the request, switchable by the reader. On a legal request the two balance choices are not offered at all: the lawyer answers the inquiries in writing, or uploads a document.

At a glance

Account
None — no login, ever.
Language
Dutch, English or Czech, detected from the request and switchable by the reader.
A legal request
No balance choice offered: the lawyer answers in writing, or uploads a document.
A refusal
Recorded as a refusal rather than as silence, which stops the reminders.
The responder portal in English: the request details (addressee, audited entity, auditor, balance date, balance per client records and deadline) and four ways to answer: confirm as stated, upload a statement, type the balance, or state that the request cannot be confirmed.
The counterparty's two minutes: no account, the request restated, and four answers, including a structured way to say it cannot confirm.

Step 3: Or just reply to the e-mail

Replying to the covering e-mail routes the message — attachments and all — straight to the right confirmation: the reply goes to the unique intake address that message was sent from, which is why nothing has to be retyped or filed. If there is no usable attachment, the e-mail body itself becomes the evidence document. Mail that matches nothing is quarantined for a person to route, never silently dropped.

Step 4: What their two minutes buys the audit

A response through the portal — or an e-mail reply from the institution the request was addressed to — upgrades that contact to network-verified, the strongest provenance tier: earned rather than asserted. A reply from anywhere else is still taken as evidence, but it is recorded as a sender mismatch and routed to a human rather than quietly strengthening the contact, because ISA 505 makes a response from an unexpected source exactly the doubt an auditor must resolve. If a responder stays silent, escalating reminders follow the batch policy with the original secure link still valid.

The responder's side, in full

Part 4: The reviewing partner

The platform is built around the approvals only a partner can give — and it makes each one inspectable years later.

Step 1: Approvals with teeth

Three things require the partner or firm-admin role and are refused to everyone else. Approve (partner) locks the sample roster: items can no longer be included or excluded, and changing the selection means generating a new sample. Reissuing an unsigned client authorization requires a recorded reason, because it withdraws an instruction already sent to the client's statutory representative. And sign-off is gated the same way, recorded with the user who gave it and the time they did, and cannot be undone. The work those approvals review stays with the auditor who performed it: alternative procedures are concluded by the engagement team, and never without a substantive written conclusion — the refusal quotes ISA 505.12 back at whoever tried: the judgement cannot be automated. A partner who approves a selection they drew, or signs off a conclusion they recorded themselves, is asked why that is acceptable, and the reason is printed beside the approval: ISA 220 asks for the work to be reviewed by someone other than the person who performed it, and the file shows where it was not.

Step 2: Overrides on the record

Dispatching to a contact below the auditor-verified tier requires a written override reason, written to the audit trail. Editing a verified contact's e-mail resets it to unverified, so the ISA 505 control re-arms itself. Nothing in the directory is deleted: contacts and organizations retire and reactivate, and a GDPR Art. 16 rectification is recorded as one. The design rule everywhere: the machine may propose, verify and assemble — a person decides, and the decision is attributable and timestamped.

Step 3: An audit trail that can be handed to a reviewer

Every recorded change carries who did it and when, and the working paper prints that trail beside the evidence it belongs to. A peer reviewer, an inspector or a regulator reads the file rather than taking the firm's word for it, years after the season closed.

What holds it all up

The commercial model, the standards the deliverable is designed to, and how a firm comes to run it.
  • Licensed, and it runs on the firm's own stack

    Confirmatica is licensed software. A licensee deploys on their own infrastructure and is the operator and controller of their instance; Bonfleur provides the licence, customization and maintenance. The demonstration runs on an instance holding synthetic data.
  • Working papers designed to the standards

    Selection rationale per ISA 530, verification controls per ISA 505 / AS 2310, documentation regenerated from the event log — designed to those documentation requirements, and packaged for handover in one ZIP.

How a firm comes to run it

  1. Step 1: A demonstration

    The season described on this site, run on a demonstration instance holding synthetic data. No firm's data is on it.

  2. Step 2: A licence

    A written licence agreement with Bonfleur s.r.o. The licence conversation covers the terms, source escrow, an inventory of every third-party component the software depends on, the deployment runbook and the maintenance agreement — under NDA, alongside the architecture and security documentation.

  3. Step 3: The customizations the firm wants

    Letter wording, the firm's own directory, the ledger formats its clients export, and the storage and e-mail providers of the firm's own stack — scoped and agreed with the firm before deployment, not guessed at in advance.

  4. Step 4: Deployment on the firm's own infrastructure

    The instance runs on the firm's own infrastructure, under the firm's control. The firm is the operator and controller of it; nothing it holds reaches Bonfleur.

  5. Step 5: Support and maintenance

    Bonfleur s.r.o. maintains and supports the deployed instance under the maintenance agreement — updates, fixes and the next season's changes reach the firm's own instance.

Architecture and security documentation is available under NDA.

The walkthrough runs on the platform itself

An enquiry names the firm and the season's volume; what follows is the product described above, run on a demonstration instance holding synthetic data, rather than a slide deck. A licence, the customizations the firm wants, deployment onto its own infrastructure, and support and maintenance by Bonfleur s.r.o. follow from there.