How Work Orders Should Connect to Property Accounting

1. Why "syncs with accounting" isn't an answer

A work order is a maintenance record, not an accounting transaction. It describes a job — what broke, who quoted it, who got assigned — and at some point that job is supposed to turn into a dollar figure on a property's books. The gap between those two things is exactly where a real integration earns its keep, and it's exactly what disappears when a product page just says it connects to QuickBooks.

Two decisions sit in that gap, and generic listicle copy skips both of them. First: has the vendor actually been paid, or only quoted or invoiced — because those are different accounting objects, not two names for the same thing. Second: when more than one vendor is tied to a single job, which one is the real expense. Get either wrong and the number that lands in QuickBooks doesn't match what actually happened.

• Whether the vendor has been paid yet, or only quoted or invoiced
• Which of possibly several vendors tied to the job is the one who actually got paid
• Which property, expense category, and (if you track it) class or location the cost belongs to
• Whether the amount matches what actually left the bank, not what was originally estimated

2. The first judgment call: an unpaid bill or an already-paid expense

In QuickBooks, a Bill and a Purchase are not interchangeable labels for "a maintenance cost." A Bill is an unpaid obligation — it sits in accounts payable until a separate BillPayment closes it out later. A Purchase records money that has already left the bank; there's no AP step, no aging, nothing left to settle. A work order by itself doesn't tell you which one applies. It tells you a job happened, not whether — or when — anyone got paid for it.

That's why treating every completed work order as billable the moment it's marked done is the wrong default. Marketing copy that promises automatic accounting sync usually means "we'll create something," without saying which of these two genuinely different objects it creates, or when. The only reliable signal that a job has actually been paid for is a bank transaction that cleared and was manually reconciled against it — which is also the only trigger that should ever generate the accounting record.

• Bill — an unpaid vendor obligation that stays in accounts payable until a BillPayment settles it
• Purchase — money has already left the bank; there is no AP step to close out afterward
• A completed work order, on its own, only proves the job happened — not that anyone has been paid
• The one dependable signal that a job is actually paid for is a cleared bank transaction, manually reconciled and tagged to that work order

3. The second judgment call: which vendor is the real expense

Here's a scenario that comes up constantly and that most work order vendor bill sync features simply aren't built to handle: a rooftop HVAC unit fails at a strip center. The incumbent vendor quotes a $1,200 compressor repair. Because the unit is older, the owner gets a second opinion, and a different vendor comes back with a $14,000 quote for a full replacement. Both vendors get tagged to the same work order while the decision is still being made — that's normal, not a data-entry mistake.

Only the $14,000 replacement is ever actually paid. If a sync tool picks "the" vendor on a work order the moment it's marked complete — first one added, most recently touched, whichever field happens to be populated — it has a roughly even chance of posting the $1,200 quote that was never paid instead of the real $14,000 expense. That's not a rare edge case on a multi-vendor job; it's the default outcome of guessing.

• $1,200 quote from the incumbent HVAC vendor for a compressor repair
• $14,000 quote from a second vendor for a full unit replacement, after a second opinion
• Both vendors tagged to the same work order while the decision is still open
• Only the $14,000 replacement ever clears the bank — that's the figure that should post, and the only one that does

4. How the push actually happens, end to end

TenantPoint's own answer to both judgment calls is the same rule applied twice: act automatically only when there's exactly one unambiguous answer, and hold anything else for a person to resolve. Zero vendors on a work order means there's nothing to map — some jobs are internal and that's fine. Exactly one vendor auto-resolves. More than one distinct vendor gets flagged rather than guessed, and it stays flagged for a person to resolve — a cleared bank transaction confirms a job was actually paid for, but it doesn't by itself tell the system which of several tagged vendors was the one who got paid.

The trigger for the actual push is narrow on purpose: a bank transaction has to clear, then get manually reconciled and tagged to the specific work order. Only then does the sync post a QuickBooks Purchase — never a Bill, since there's no unpaid-obligation state anywhere in this flow to justify one. Property is carried as a Location at the transaction header; expense category is carried as a Class on the line, since Class on a Purchase only ever applies at the line level, unlike Location, which stays header-level on every synced transaction type. Every push is keyed to that local transaction's row id before any QuickBooks call goes out, so a retried or interrupted sync can't double-post the same $14,000 expense. And if an accountant later reclassifies that Purchase directly inside QuickBooks, TenantPoint doesn't silently overwrite it on the next sync — the edit is detected and flagged as a conflict for a person to accept or ignore.

• Bank transaction clears and appears automatically once the property's bank account is connected
• A person reconciles it and tags it to the specific work order
• The push posts as a Purchase, dated to when the money actually left the bank — never a Bill
• Location carries the property at the transaction header; Class carries the expense category on the line
• An accountant's later edit inside QuickBooks is flagged as a conflict, never silently overwritten

5. What to check before you trust any work-order-to-accounting sync

If you're comparing platforms and one of them lists accounting integration as a feature, the single bullet point isn't enough to evaluate. Ask about the mechanics directly — most vendors can answer these questions if you push past the marketing page, and the answers tell you more about maintenance cost tracking by property than the feature name ever will.

• Does it wait for a cleared, reconciled bank transaction, or does it push from an estimate or an assigned vendor the moment a work order is created?
• Does it distinguish an unpaid Bill from an already-paid Purchase, or does everything land as one generic "expense"?
• What happens when more than one vendor is tied to a job — does it guess, or hold it for a person to resolve?
• Can you trace a number on a property's maintenance cost report back to the exact bank transaction that produced it?
• If an accountant edits the record directly in your accounting software, is that edit protected, or silently overwritten on the next sync?