Property Management Data Integration: Work Orders, Leases, Accounting

Ask four people at a property management company what the rent is on unit 214 and you can get four answers. The property system has a signed lease. Accounting has a recurring charge. The maintenance tool has a unit that may not be numbered 214 any more. The owner statement has a figure from whenever the last export ran.

None of those systems is broken. They disagree because nobody wrote down which one is right. The National Multifamily Housing Council and RealFoundations, in their 2023 Customer Experience Technology Report, drawn from responses by 40 multifamily firms, found that most multifamily operators use 10 to 20 different solution providers. This post is the ownership map we draw for the portfolios we build for: who owns the unit, the lease, the work order and the ledger, and what goes wrong where any two of them touch.

Why does the unit record go wrong before anything else?

Everyone assumes the unit list is fine. Nobody audits it, and it is the join key under every other record.

Units get matched across systems by a label a person typed: "214" in one place, "Unit 214" in the next, "APT 214" on the vendor invoice, "214-B" in the file from the prior manager. A near-match is not a match, so a sync either creates a second unit or attaches work to the wrong one.

State drifts too. A unit taken out of service for a renovation is marked down in the maintenance tool, still reads rentable on the availability feed, and still carries a charge in accounting because the lease was never terminated there. The resident moved out in June. The ledger has been billing since.

The property management system owns the unit and the property above it. Every other system stores the identifier it issued rather than a typed label, and any tool that cannot hold a foreign identifier gets one crosswalk table. An AI leasing agent quoting availability is only as accurate as the unit list beneath it.

Where does the lease live, and what is allowed to change it?

The lease carries start and end dates, base rent, the escalation schedule, term options, concessions, the notice period and the deposit agreed at signing. All of it belongs to the property management system, where the executed document is filed.

Accounting bills from it, the portal displays it, the renewal workflow reads dates off it. None of them write back.

The seam failure is a rent change that stops halfway. A renewal gets signed on the twelfth, effective the first of next month, and the recurring charge in accounting is still set to the old amount because updating it was somebody's Monday task. The resident pays what they are billed. The gap surfaces on an owner statement two months later, and now you are asking a good resident for back rent you never invoiced. A renewal manager agent makes that worse if the new rent it records never reaches billing.

The rule that closes it: a rent change originates on the lease, carries an effective date, and posts to the ledger as a dated schedule change rather than a hand edit to a charge. Mid-term escalations follow the same path, because an increase living only in a PDF does not happen. The renewal calendar works the same way: lease end dates kept in a spreadsheet copy go stale.

Where does a work order live once it leaves the office?

The work order legitimately crosses two systems, which is why splitting it by record instead of by field causes trouble.

Intake belongs to the property side: which unit, which resident, what they reported, whether entry is permitted, and the open or closed status residents and owners see. Everything after dispatch belongs to whichever tool your techs and vendors actually open: assignment, schedule, technician notes, parts, before and after photos, completion timestamp. Cost belongs to accounting.

The failure is a job that closes in the field and never posts. A tech marks a water heater replaced on Friday. The resident sees a completed request. The vendor invoice arrives three weeks later with no work order number on it and gets coded to general repairs at the property level rather than the unit. Per-unit maintenance cost is now a guess, and the unit eating a quarter of the budget looks average.

Completion photos that live only in a field app go unreachable the week a former resident disputes a deposit deduction.

So one identifier travels from intake to invoice, no invoice gets coded without it, and photos sync back to the unit record. The maintenance coordinator agent we build writes into that shape. The three property workflows worth automating first all assume it exists.

What is allowed to post to the ledger?

Accounting owns money: charges, payments, credits, delinquency status, deposits held, owner distributions and the statements built from them. Three things post and nothing else does. The lease posts scheduled rent and fees. The work order posts costs, each carrying a unit and an expense account. The payment processor posts receipts.

Everything else reads, and it matters most where two systems each compute delinquency. The portal shows a resident current because a payment landed this morning, the collections list built from last night's export still has them on it, and a notice goes out to someone who paid.

Deposits drift the same way. A held amount tracked as a line on the property record and again as a liability in accounting agrees until the first partial refund, then diverges quietly for the rest of the tenancy.

Field-level conflict rules for a two-way sync matter when both systems can originate a change. Where money is concerned only one can: the balance in accounting wins, and a posted transaction is never overwritten.

How do you get the map written down?

It is a scoping exercise, not a build task, and it happens before anyone touches an API. Take one record type at a time. Name its owning system. List every other system holding a copy. For each field in each copy, write the direction and the thing the sync must never overwrite. Name who gets alerted when it stops.

Most operators fill the first two columns in an afternoon and stall in the fourth, which is the column that pays for itself. Arguments about what a sync must never touch are arguments about how your operation runs.

What a build costs depends on how many systems sit in the map, how well each exposes its data, and how many fields move both ways. All three get settled on the call, which is why data integration work starts with the map.

FAQ

What is property management data integration?

It is connecting your property management system, maintenance or field service tool, accounting package and resident portal so every record has one owning system and the rest read a current copy. The design work is deciding who owns the unit, the lease, the work order and the ledger. The build follows that decision.

Which system should own the rent amount?

The property management system, because the executed lease lives there and that document settles any dispute. Accounting bills from it and never writes back. A rent change should originate on the lease with an effective date and post to the ledger as a scheduled change, not as a manual edit to a recurring charge.

Where should a work order cost be recorded?

In accounting, coded to the specific unit and the right expense account, carrying the same work order identifier the request was created with. If an invoice can be coded without that identifier, some costs will land at the property level instead of the unit, and per-unit maintenance reporting stops being trustworthy.

How do you stop the same unit existing twice?

Match on an identifier the property management system issued rather than on a typed label, since unit naming drifts between tools and across ownership changes. Where a tool cannot store a foreign identifier, keep one crosswalk table, maintained in one place, and reconcile unit counts across systems on a schedule.