Why auditing a 1C entity is slow
Group auditors rarely say a 1C subsidiary is unauditable. They say it takes longer, and the fee reflects that.
Three things drive the time. Interfaces and documentation are not in English, so every request needs a translator or the local accountant. Sample testing cannot be done by the audit team directly — they ask, someone extracts, they receive a spreadsheet. And the extraction itself is done by the same person whose work is being tested.
That last point is the one that matters most and gets discussed least. It is not an accusation of anything; it is a control weakness that any auditor is obliged to note.
Language is the smaller half
The instinct is that the problem is language, and that a translation layer would fix it. It would not.
An auditor needs to trace a figure from the financial statements down to a source document, and to do it independently. That requires being able to navigate the system, filter, drill into a balance and open the underlying entry. A translated screenshot of a report does not permit any of that.
So the useful question is not "can we get this in English" but "can the audit team run their own queries without asking anyone".
What changes after a move to Business Central
| Before | After |
|---|---|
| Auditor requests an extract, local accountant produces it | Auditor queries the ledger directly with read access |
| Interface and reports in Ukrainian only | Interface language set per user; the same records render in English |
| Sampling agreed in advance and prepared | Sampling done by the audit team from live data |
| Change history depends on what was configured | Change log on selected tables, plus posting date and user on every entry |
| Prior periods editable unless someone blocked them | Accounting periods locked; posting into a closed period requires a permission |
The row that reduces audit hours most is the first. When the audit team can extract their own samples, an entire category of back-and-forth disappears, and so does the control weakness of self-extraction.
Multi-language on one database is worth being precise about: it is not a translation layer or a synchronised copy. The Kyiv accountant works in Ukrainian, the audit team opens identical records in English, and both are looking at the same rows.
The audit trail, specifically
What exists by default and what has to be switched on — this distinction causes most of the disappointment.
By default on every entry: the posting date, the document date, the user who posted, the document number and the link back to the source document. This is not configurable and cannot be edited after posting. Corrections are made by reversing entries, which stay visible.
Switched on selectively: the change log, which records who modified which field on which record. It is off for most tables and should be enabled deliberately rather than everywhere — enabling it globally inflates the database for little benefit.
A sensible minimum for an audited entity: customer and vendor master records including bank details, item costing setup, posting group configuration, and changes to user permissions. That last one is the most commonly forgotten and the one an auditor is most likely to ask about.
Not automatic: period locking. Closing an accounting period is an action someone has to take. If nobody does, prior periods stay open and an auditor will find postings dated into closed months. The mechanics are in period close.
Giving auditors access without giving them everything
A practical arrangement that works better than sending exports.
Create a user with read-only permissions across the ledger and reporting, no ability to post, and no access to master data changes. Business Central restricts at four levels — objects, actions, records and periods — so a read-only auditor role is straightforward to build. The mechanics are in security and permissions.
Three points worth agreeing in advance with the group:
- Duration. Access for the audit window, removed afterwards. Put the removal date in the same email as the grant.
- Named individuals. Not a shared "auditor" login. If access is shared, the change log stops meaning anything.
- Data scope. If the environment holds several entities, restrict the auditor to the one being audited.
This arrangement is also what makes the earlier control weakness go away: the sample is drawn by the person testing it, not by the person being tested.
What this does not fix
Two things, so the expectation is right.
Migration does not clean the history. Prior-year figures come across as balances, not as auditable detail, unless you pay to migrate detail — and that is usually the most expensive line in the project. For the first audited year after a move, the comparatives still live in the old system.
Statutory reporting is still local. Business Central does not include Ukrainian statutory forms in the base product; they come from the partner localisation. An auditor testing statutory compliance is testing the localisation, not the platform.
Frequently asked questions
Can auditors work directly in Business Central?
Yes, with a read-only role. Access is restricted at four levels — which pages open, which actions are permitted, which records are visible and which periods accept postings — so an auditor can query the ledger without any ability to post or change master data.
Does Business Central keep a full audit trail?
Partly by default and partly on request. Every posted entry carries posting date, document date, user and a link to the source document, and cannot be edited afterwards. The change log, which records field-level edits, is off for most tables and should be enabled selectively.
Will the auditors see records in English?
Yes. Interface language is set per user against a single database, so the local team works in Ukrainian while the audit team opens identical records in English. This is not a translation layer or a copy — both are looking at the same rows.
Does migrating fix prior-year comparatives?
No. Prior periods come across as balances rather than auditable detail unless you pay to migrate the detail, which is usually the most expensive line in the project. For the first audited year after a move, comparatives still live in the old system.
What should we switch on before an audit?
Period locking, and the change log on four things: customer and vendor master data including bank details, costing setup, posting group configuration, and user permission changes. The last is the most commonly forgotten and the one auditors ask about most.