Management Company Portal: Where Accounting and Charges Break Down
Charges diverge from meter readings because the data lives in three places: accounting calculates in the accounting system, readings are collected via paper receipts and phone calls, and the resident sees the number only on the monthly bill.
Any correction means a recalculation, a paper application, a manual reconciliation — and the discrepancy accumulates until the quarterly inventory. A management company portal closes this gap: readings, charges, and requests converge into a single record per account.
The most expensive part is collecting meter readings.
While residents dictate numbers over the phone or bring them to the office, an operator enters them by hand — hence typos, lost requests, and calls asking "why is my amount this high." A resident self-service portal flips the scheme: the owner submits readings themselves, the system checks them for outliers against previous periods, and immediately shows a preliminary calculation. Accounting receives a ready dataset instead of a stack of paper.
Tracking owner requests breaks down for the same reason — a request lives in a logbook at the front desk, not in the system. No history, no assignee, no deadline.
Utility charge automation without a single request registry delivers only half the effect: the money gets calculated, but the causes of underpayments and disputed bills surface only in complaints.
Let's break down how this gets closed: from the data schema and roles to the reconciliation procedure, so that charges, readings, and requests converge without manual labor.
What the portal delivers: operating modes and measurable effect
The management company portal operates in two fundamentally different modes, and the choice between them determines how many manual operations remain for the accounting department and the passport desk.
In synchronous mode, billing runs on a schedule, data from the billing system is pulled in batches, and discrepancies in personal accounts are resolved manually.
In event-driven mode, billing and recalculation happen as changes occur: a period closes, meter readings arrive, the composition of residents changes. The difference is visible on the very first reconciliation.
Billing timelines and the share of manual operations
Synchronous mode provides a predictable window: billing is generated overnight, but any edits after export mean a re-run and manual reconciliation.
Event-driven mode shortens the cycle to hours, because recalculation is triggered in a targeted way for a specific personal account rather than the entire array.
The share of manual operations drops because readings, benefits, and debts are pulled from the billing system automatically, and the operator intervenes only in disputed cases.
Failure class
Batch export is vulnerable to "partial success": half the accounts updated, half did not, and the discrepancy surfaces in the invoices.
Event-driven processing with idempotent operations and a retry queue eliminates this failure class — a failure on one account does not block the others, and a failed operation is retried without duplicates.
| Option | When it fits | Limitations |
|---|---|---|
| Synchronous batch mode | Small housing stock, stable billing, billing once a month | Manual reconciliation for discrepancies, sensitivity to partial failures |
| Event-driven mode with a queue | Multiple buildings, frequent recalculations, online readings | Requires idempotent operations and queue monitoring |
| Hybrid: batch + events | Large housing stock, migration from a legacy system | Harder to maintain, requires a unified data schema |
Integration with the billing system is built through an exchange layer that normalizes personal accounts and charges, so changing the billing system does not require rewriting the personal account portal.
We build such a layer on PostgreSQL with an operations log — every billing record is traceable to its source, and rollback is done without losing history.
How we implement the portal: stages of engineering work
Implementation of a management company portal begins not with building the personal account UI, but with an audit of housing and utility accounting.
At this stage we look at where the charges come from: 1C, a custom-built database, accounting spreadsheets, paper meter-reading rounds. This determines the integration scheme — export of personal accounts, meter readings, charges, and payment receipts.
A portal that does not reconcile with the current accounting will not take hold: residents will see one set of amounts, the accounting department another.
After that we work in iterations: first a contour that covers the critical scenario, then expansion. This way employees see results sooner, and we catch data discrepancies on live operations rather than in a demo.
- Audit of housing and utility accounting. We examine data sources, the structure of personal accounts, and the regulations for charges and meter-reading rounds. We record what gets moved into the portal and what stays in the accounting system.
- Designing the integration scheme. We determine how the portal exchanges data with the accounting system: one-time, on a schedule, or on an event. We define the formats, frequency, and behavior when an export fails.
- Personal account prototype. We assemble the key screens: meter readings, charges, payment receipts, requests. We agree on them with the client before development so the logic doesn't have to be redone.
- Configuring the personal account and roles. We separate access: resident, dispatcher, accountant, building supervisor. We set up notifications, request history, and linking multiple personal accounts to a single user.
- Development and integration. We build the account, connect the exchange with the accounting system, and test on real data from past periods — reconciling charges and meter readings down to the penny.
- System handover and training. We deploy on the client's production environments, hand over access credentials, regulations, and documentation, and train employees to work with requests and exports.
- Post-launch support. We run the first billing period together with the client's team: we analyze discrepancies and fine-tune notifications and reports.
Each stage ends with an artifact: a data map, an integration scheme, an approved prototype, configured roles, documentation. System handover is not a final presentation, but a working contour in which employees are already running operations.
How is a management company portal different from an ordinary website with a request form?
A website with a request form is a storefront: a visitor submits an inquiry, it lands in an inbox, and then it is manually distributed across logs and to the responsible staff.
A management company portal is a working tool where a request, a charge, and a meter reading live in a single connected data model. The difference shows up not in the interface, but in what happens after the "Submit" button is pressed.
On an ordinary website, a request is just text in an email: there is no status, no assignee, no deadline, and no history.
On the portal, it immediately gets a number, a category, an address, and a period, is linked to the personal account and the building, and goes into the queue for the right responsible person.
The dispatcher sees what is overdue, what is in progress, and what is closed with a work completion act, while the resident sees the same status in their personal account without making phone calls.
Request automation eliminates manual transfer between email, spreadsheets, and messengers — this is exactly the stage where deadlines are missed and complaints appear.
The features of the personal account go beyond "viewing a request." A resident submits meter readings, sees charges and payment history, downloads receipts and acts, votes on building matters, and submits inquiries about a specific apartment.
The management company, for its part, gets a summary for the building: who has not submitted readings, where debt is growing, which works repeat month after month. This is no longer news publishing, but an operational loop with roles and access rights.
The key difference between a website and a portal lies in the source of truth. On a website, data lives in the text of pages; on a portal, it lives in a database where every entity is linked to the personal account, the building, and the period.
That is why on a portal you can build a report for the building, export a register of charges, reconcile readings with the calculation, and see how many requests were closed on time. A website fundamentally cannot solve such tasks — it does not store history.
That is precisely why a management company portal is designed from processes, not from a mockup: first you describe how a request travels from the resident to the act, how services are charged, and who sees what. The interface is then assembled around that logic.
If you start with beautiful pages, you will end up with the same website with a form, only more expensive.
Case study: how a management company portal eliminated manual meter reading entry
Before the portal was introduced at the management company, readings were collected manually: residents dictated numbers over the phone, the dispatcher transferred them into a spreadsheet, and accounting reconciled discrepancies before billing.
For 4,200 accounts, there were about 1,800 calls per month, and up to 12% of readings arrived late or in the wrong format — billing slipped by 8–10 business days, and some requests were lost between shifts.
What was changed
The flow was split into three independent loops. The personal account accepts readings with input validation: the meter is checked against the previous value, and a jump beyond the allowable deviation goes for confirmation rather than into billing.
Requests received a status model with an owner and a deadline — a request cannot be closed without a completion note. Export to billing runs on a schedule, not based on manual reconciliation.
What the result was
The share of manual operations in reading collection dropped from 100% to 6% — only disputed cases and buildings without meters remained.
The billing period shrank from 8–10 to 2 business days: data arrives evenly throughout the period rather than in an avalanche during the last three days.
Lost requests — zero, thanks to the mandatory status and transition log, and repeat requests for the same issue fell by roughly threefold.
| What was measured | Before | After |
|---|---|---|
| Manual reading entry | 100% | 6% |
| Billing period | 8–10 days | 2 days |
| Readings with errors | 12% | 1.5% |
| Lost requests | regularly | 0 |
| Phone calls | ~1,800/month | ~400/month |
The load on the dispatch desk should also be considered separately: the freed-up time went to site inspections and work with debtors rather than transferring numbers from a log.
This is the effect that the client usually does not include in initial expectations, yet it turns out to be the most noticeable for residents.
Technically, the portal is built on an integration with the existing billing system through an exchange layer — the accounting systems were not rewritten, and data flows in both directions.
1С:Расчёт квартплаты remains the source of billing, and the portal operates as the intake and control loop in front of it.
Compatibility, migration, and access concerns
A management company portal is rarely deployed on a blank slate — it usually sits behind billing, charges, a registration desk, and years of accumulated data.
That is why the customer's first question is usually not "how does it work" but "how will it fit with what we already have." Below are the concerns most often raised by technical leads.
What happens to the current billing and charges?
The portal does not replace billing — it sits on top of it: the personal account reads charges and balances through an integration layer, and sends payments and meter readings back.
Compatibility with billing is determined by the exchange format — file export, API exchange, or an intermediate database. If the system has no open interface, we build an adapter that pulls data on a schedule and maps it to a unified model. Charges remain in the accounting system, while the portal shows the resident the current picture.
What if the accounting data is "dirty"? Management company data migration starts with profiling: we look at duplicate account numbers, discrepancies in areas, and broken owner links.
We move data into a staging environment, reconcile checksums for each building, and only after convergence do we enable live exchange. We record discrepancies in a report — you see what did not match and why.
Can changes be rolled back? Yes. Every release comes with a reverse schema migration, and billing exchange is toggled with a flag — if something fails, we return to the previous environment without losing charges. We test rollback on a copy of production data before rollout, not after.
How are employee access rights separated? Roles are built on the principle of least privilege: an accountant sees charges, a registration clerk sees registration data, a dispatcher sees requests but not finances.
Employee access rights are managed through a unified role model with an action log — you can see who opened an account card and when.
What is included in the documentation handover? The billing integration scheme, a description of the data model and migration rules, the access role matrix, the release rollback procedure, and support team instructions — all within your environment, with no dependency on us.
What you receive:
- a scheme for integrating the portal with billing and accounting systems;
- a management company data migration map with reconciliation rules and a discrepancy report;
- a role matrix of employee access rights and an action audit log;
- a change rollback procedure and the order for switching environments;
- a documentation set for support and staff training;
- a portal development plan after launch.
Describe your task — your current accounting system, the volume of data by buildings and accounts, and your role requirements. We will come back with an estimate and a work plan for integration and migration.
