Closing KS-2, KS-3, and KS-6: from site volumes to contractor payment

Five roles take part in month-end closing: the contractor counts completed work on site, site supervision checks it in practice, the technical office reconciles it with the contract estimate, accounting waits for the document, and finance manages the payment calendar. While these roles work in different files and systems, the month closes not on data but on emails and calls.

This creates the same set of problems across all companies: volumes submitted but not confirmed; act compiled but doesn't match contract line items; document sent for signing and vanishes; contractor doesn't understand where their money is and calls accounting. No symptom is solved by a new act form. They're solved by linking the steps—a chain where confirmed volumes become an act, and the act becomes payment without manual transfers.

The entry point into this chain is the estimate and the volumes. How volumes get into the estimate and into the accounting system is covered separately on the page integrating TIM/BIM with 1C. This page covers what happens next: how accepted work becomes money.

"A month without closing" almost never means the contractor did nothing. Much more often it is a schedule gap: the working documents for the next type of work arrived later, there is no estimate yet, and no contract line item yet, so there is nothing to close formally, even though crews were working on site all month.

For the contractor, stalled KS processing means a cash gap: wages and materials are paid, revenue is not recognized, and the next tranche depends on closing the previous period. For the client, plan-versus-actual is distorted: progress on the project looks lower than it really is, decisions on deadlines are made on an understated picture, and the next month brings double the closing volume.

This should be fixed not in accounting, but earlier. The system must show discrepancies in advance: which work types lack labor sheets, where estimates aren't ready, which volumes are already confirmed by construction control and awaiting contract items. Then through month-end, you have options—accelerate estimate release, issue a change order, or close the period at claimed cost with subsequent adjustment—rather than explaining post-hoc why the document wasn't completed.

Volumes differ between design and working documentation almost always—a normal project course, not a design error. In closure, discrepancies appear as minus and plus closures: volumes removed from one item and added to another process through one document for the period. The basis is always specific—a revision estimate, design change, or amendment, with author, date, and amount.

For this to work, estimate lines, contract, confirmed volume and act must be line-item linked and survive document re-issuance. Without linkage, discrepancies are compiled in Excel, and after a quarter no one can explain why the contract total diverged from the act total or what change caused it.

A separate discipline—the volumes themselves: how they convert to work and materials, where consumption coefficients come from, and how to handle non-modelable elements. We cover calculation methodology and reference requirements in the article on work quantity statement.

Contractor employees lack corporate accounts at the customer. This is not an administrative detail but a working condition for the entire route: if only the developer's employee can submit field volume, submission again becomes file exchanges and phone calls.

Three requirements typically emerge last and cost the most to implement. First—single sign-on for all developer services instead of individual passwords. Second—event-driven access revocation: contractor employee termination or contract closure must immediately revoke access, not await the next account audit. Third—fine-grained permissions by object, building and work type: a contractor on one section should not see contract volumes of adjacent sections.

That's exactly what we did. For GK TOCHNO in two months, we launched an MVP unified portal: deployed and configured Keycloak IdP, enabled authentication via the Active Directory master system. In parallel, in three weeks we built a service showcase—the first stage of the dashboard. Before the project, external users had no access at all: information was exchanged on paper, then digitized and reports were built manually, while provisioning internal users took three weeks to two months.

In a construction planning and control system for a developer in CIS's top five by construction volume, site reporting stopped being monthly: data began arriving two or three times a week instead of once a month. For a client where every day of delay on one project costs about RUB 200k, that is the difference between reacting in time and acting after the fact.

In a developer's accounting close project, completed work was linked to the report, act, invoice, and UTD as a single confirmation package: finance can see exactly what was accepted and what supports it, without separately checking the context for each item.

In a material procurement project for a developer of the same class, prepaid purchasing became 4.9 times faster, and postpaid purchasing 3 times faster. The adjacent task in the same system is construction materials procurement automation.