How the QuickBooks Online Sync Works

If your property is on the Premium accounting plan and you have connected QuickBooks Online, URBI keeps your QuickBooks books in step with your URBI books automatically. You do your day-to-day accounting inside URBI, and the matching entries show up in QuickBooks on their own. This guide explains what moves in each direction, in what order, and why you never end up with the same transaction booked twice.

Who this is for: Property managers, board members, and staff on the Premium accounting plan whose property has an active QuickBooks Online connection. If you are on Basic or Kore, or you have not connected QuickBooks, none of this runs and nothing described here appears in URBI.

The core idea: URBI is the system of record

The most important thing to understand is the direction of authority. URBI is the system of record, and URBI authors your accounting. You create invoices, record expenses, post journal entries, and take payments inside URBI. URBI then writes the equivalent objects into QuickBooks for you. QuickBooks is treated as a mirror of what URBI already decided, not as a second place where you do the same work.

There are only two exceptions, where information flows the other way, from QuickBooks back into URBI:

• QuickBooks Payments - when a customer payment against an invoice is recorded directly in QuickBooks, URBI pulls it back so your invoice shows as paid in URBI too.
• QuickBooks Bill Payments - when a bill (an expense) is paid directly in QuickBooks, URBI pulls it back so the expense shows as paid in URBI too.

Everything else is one-way, from URBI to QuickBooks. You should think of URBI as the place where accounting happens and QuickBooks as the place it is reflected, with those two payment cases as the only "read back" from QuickBooks.

What URBI pushes TO QuickBooks

When you take one of these actions in URBI, URBI creates the matching object in QuickBooks:

• Invoices you finalize (anything past Draft) become QuickBooks Invoices. An invoice that is a credit note, or one you write off, becomes a QuickBooks Credit Memo instead.
• Expenses you approve become QuickBooks Bills. Voiding an approved expense removes the matching Bill in QuickBooks.
• Journal entries you post become QuickBooks Journal Entries. Opening balances are pushed as journal entries too.
• Payments you record against invoices become QuickBooks Payments. Refunds become the QuickBooks equivalent (a Refund Receipt, Credit Memo, or Vendor Credit depending on the situation).
• Expense payments (paying a bill) become QuickBooks Bill Payments.
• Billing account name changes update the matching QuickBooks Customer, and vendor name or email changes update the matching QuickBooks Vendor, so names stay consistent on both sides.

What URBI pulls BACK from QuickBooks

Only two things flow from QuickBooks into URBI, and both are payments:

• A customer payment recorded in QuickBooks against an invoice is pulled into URBI and applied to the matching URBI invoice.
• A bill payment recorded in QuickBooks against a bill is pulled into URBI and marks the matching URBI expense as paid.

The pipeline in plain terms: queue, drain, push

Behind the scenes, URBI does not call QuickBooks the instant you click Save. Instead it uses a simple three-step pipeline so that a busy day of accounting does not overwhelm QuickBooks and so that a temporary QuickBooks outage never loses your work.

1. Queue. The moment you post a qualifying transaction (an approved expense, a posted journal entry, a finalized invoice, a recorded payment, and so on), URBI writes a small "to do" note into a sync queue. This note just says "property X needs entity Y pushed." It is fast and happens as part of saving your transaction.

2. Drain. On a short repeating cycle (roughly once a minute), a background worker picks up the queued notes for your property, oldest first, and works through them. It also puts them in a sensible order: customers and vendors are handled before the invoices and expenses that reference them, and those are handled before the payments that reference them. This ordering means QuickBooks always has the "parent" record it needs before the "child" record arrives.

3. Push. For each queued item, URBI builds the correct QuickBooks object and sends it. When QuickBooks accepts it, URBI records the link between the URBI record and the new QuickBooks record (so it always knows the two are the same thing), and marks the item as synced. If QuickBooks rejects it or is unreachable, URBI marks the item as failed and can retry it later, for example after you reconnect QuickBooks.

You do not start, schedule, or babysit any of this. It runs continuously in the background as long as you are on Premium and connected.

The anti-double-book design (echo suppression)

Here is the question everyone asks: if URBI pushes payments to QuickBooks, and URBI also pulls payments back from QuickBooks, what stops a payment from bouncing back and forth and getting booked twice?

The answer is echo suppression. When URBI pulls something back from QuickBooks (a QuickBooks Payment or Bill Payment), it stamps that record as "this came from QuickBooks." Later, when the sync queue looks at that same record to decide whether to push it back out, it sees the stamp and deliberately skips it. The item is marked as suppressed instead of pushed. In other words, a payment that originated in QuickBooks is recorded in URBI for your books, but URBI knows never to send it back to QuickBooks, because QuickBooks already has it. That is what closes the loop safely.

This is why you will sometimes see a transaction labeled "From QuickBooks" rather than "Synced" in URBI (covered in the sync-pill guide). That label is the visible sign of echo suppression: it means "this one was pulled in from QuickBooks and is intentionally not pushed back," which is a healthy, correct state, not an error.

A walked example

Say a resident owes $500 and you want to bill and collect it.

1. You create and finalize an invoice for $500 in URBI. URBI queues an invoice push. Within about a minute, the drain worker sends it to QuickBooks, which creates a $500 Invoice. URBI records the link and the invoice shows as Synced.

2. The resident pays $500, and you record the payment in URBI. URBI queues a payment push, sends it to QuickBooks, and the QuickBooks Invoice now shows paid. The payment shows as Synced in URBI.

3. Alternatively, your bookkeeper records that $500 payment directly in QuickBooks. Now the flow reverses: URBI detects the QuickBooks payment, pulls it in, and applies it to your URBI invoice so it shows as paid. Because the payment came from QuickBooks, URBI stamps it and, when the sync queue later considers it, deliberately skips pushing it back. In URBI that payment shows as From QuickBooks, and QuickBooks is never asked to record it a second time.

Either way, both systems end up agreeing that the invoice is paid, and the money is booked exactly once.

Edge cases and good to know

• Drafts do not sync. An invoice only pushes once it is past Draft; an expense only pushes once it is Approved; a journal entry only pushes once it is Posted. Work in progress stays private to URBI until you commit it.
• Voids are handled, not ignored. Voiding a posted journal entry, an approved expense, or a finalized invoice sends the matching removal or reversal to QuickBooks, so the two sides stay balanced.
• Nothing runs off Premium or when disconnected. The entire pipeline checks that the property is Premium and connected before doing anything. If you are not both, no queue entries are made and no pushes happen.
• Retries after reconnecting. If QuickBooks was disconnected and some items failed for authorization reasons, reconnecting can re-queue those failed items so they push through on the next drain, without you re-entering anything.
• Duplicate protection. URBI keeps a link between each URBI record and its QuickBooks counterpart. If a push is retried, URBI reuses the existing link rather than creating a second QuickBooks record, so retries never double up.
• Names sync one way too. Renaming a billing account updates the QuickBooks Customer; renaming a vendor (or changing its email) updates the QuickBooks Vendor. This keeps reports readable on both sides.

FAQs

Do I have to click anything to sync? No. As long as you are on Premium and connected, syncing runs automatically in the background on a short cycle. You just do your accounting in URBI.

Can I do my accounting in QuickBooks instead of URBI? Not for the general workflow. URBI is the system of record and authors invoices, expenses, journal entries, and payments. The only things URBI reads back from QuickBooks are customer payments and bill payments. If you enter, say, a journal entry directly in QuickBooks, URBI will not pull it in.

Why does one of my payments say "From QuickBooks" instead of "Synced"? Because it was recorded in QuickBooks first and pulled into URBI. URBI deliberately does not push it back (that would double-book it), so it gets its own distinct label. This is correct and expected. See the sync-pill guide for the full list of states.

What happens if QuickBooks is down when I post something? Your transaction is safe in URBI and the sync note stays queued. When QuickBooks is reachable again, the next drain cycle pushes it through.

Will syncing ever change my URBI numbers? The only inbound changes are the two payment cases (a customer payment or bill payment made in QuickBooks marking your URBI invoice or expense as paid). Nothing else in QuickBooks reaches back into URBI.