08 Internal cloud for an audit firm: counterparties, reporting, and document workflow

By this point we had already automated external requests to counterparties for the company and deployed a mail server. This task exposed a problem one level up: the automated piece worked, but everything around it remained scattered across places that had nothing to do with each other.

Counterparty data lived in files and in employees' heads. Reporting that needed re-verification sat in exports and spreadsheets. Audit documents sat in folders on disks. Accounting sat in 1C, separate from everything else. The same counterparty existed in four places, in four slightly different forms, and which one was correct got sorted out as the work went along.

The same counterparty existed in four places, in four slightly different forms, and which one was correct got sorted out during the review.

A second problem grew out of this: access. As long as data lives in files, the question of who among the staff sees what has no technical answer: a folder either has access rules or it doesn't. For a company working with the financial data of other people's businesses, this is not a minor inconvenience, it's a direct risk.

And a third: any attempt to bring order ran into a requirement that was not up for discussion. No external services. An audit client's data does not get uploaded to someone else's cloud, and that's required both by the nature of the data and by the industry regulation the company operates under.

A system the company itself calls an internal cloud, and the name is accurate: in its capabilities it's a cloud service, a web application accessible to employees from their workstations, with a shared database, file storage, and access rights. In its location it's the exact opposite: everything is deployed in a cluster on the client's own servers.

The core of the system is a single counterparty database. The same counterparty that used to exist in four forms became one record, to which everything else is attached: work history, documents, requests sent and answers received, the reporting under review.

In its capabilities, this is a cloud service. In its location, the servers sit on the client's own premises. That exact combination was the task.

On top of this database sits re-verification of counterparty reporting, which is the whole reason the auditor holds this data in the first place. A reconciliation that used to mean opening an export, opening a spreadsheet, and comparing by eye became an operation inside the system, where both sides of the comparison already sit next to each other and are linked to the same counterparty.

Alongside it, document workflow: audit documents are stored not in a folder on a disk but in the system, linked to the counterparty and the review, in file storage on the company's own servers. Plus a set of supporting modules that grew out of practice: things employees used to do by hand, the same way every time.

Access control was designed not as a setting but as part of the system's underlying model. In audit work, an employee should not see everything: a review has a defined set of participants, a client's data has a defined circle of people allowed to see it, and that circle is narrower than the company's full staff list.

Access rights are tied to an employee's role and to their involvement in a specific engagement. This answers a question that previously had no answer at all: who exactly had access to this client's data. While documents sat in network folders, the honest answer was "whoever had access to the folder."

For a company that is itself regularly audited, this is not about convenience. It's about the ability to show how access to data entrusted to it is structured, and to show it through how the system is built, not through a promise.

The system did not replace the accounting system and never tried to: 1C remains the place where the company's money is accounted for. Instead, an exchange was set up: data both sides need moves between the systems rather than being carried over by hand.

A second link connects to the automation of external requests built earlier. Requests to counterparties and the answers received stopped being a separate process: they are now tied to the counterparty record and to the review in the shared database. The same mail infrastructure we had deployed earlier now also handles correspondence inside the system.

The request automation from the earlier project stopped being a separate tool and became a function of the shared system.

The two projects came together as one: the first closed the channel of communication with the outside world, the second closed the reason that communication existed in the first place.

Local deployment was not a preference, it was the boundary within which every other decision got made. An audit firm works with the financial data of other people's businesses; that data cannot be moved to a third-party cloud, either because of what the data is or because of the requirements around how it must be stored.

So the only thing that stayed "cloud" was the system's capabilities, not its location. The application, the database, file storage, cache, and exchange with 1C all run in a cluster on the client's own servers. Files sit in storage with an S3-compatible interface, deployed in the same place. That gives the convenience of a familiar protocol without moving documents outside the perimeter.

A cluster was chosen not to chase a trend: the system became the company's primary working tool, and its unavailability stops work entirely. Cluster deployment is the answer to the question of what happens when one server goes down.

The operations side matters as much as the code. The system is hosted at the client's premises and maintained there too, and that's part of the requirement, not a side effect of it.

Six months of development gave the company not a set of improvements but a different way of working. Data stopped being scattered files and became a system in which a counterparty, its reporting, its documents, and its correspondence form one connected whole.

Questions that previously had no technical answer now have one: who has access to a given client's data, where documents are physically stored, which of four versions of a counterparty record is the correct one. In an industry where the company itself is regularly audited, being able to answer questions like this is part of professional standing.

And separately: the system stayed inside the perimeter. The company got everything a cloud service provides, without handing anything to the outside.