What Syncs to QuickBooks Online: Reference
The QuickBooks Online integration is available on the PREMIUM plan. Once a property connects its QuickBooks Online company, URBI keeps your books in sync automatically: most records flow one...
Last updated
The QuickBooks Online integration is available on the PREMIUM plan. Once a property connects its QuickBooks Online company, URBI keeps your books in sync automatically: most records flow one direction, from URBI out to QuickBooks, and a small, deliberate set flows back the other way. This article is the complete reference for what becomes what, which direction each record moves, what never syncs, and how URBI guarantees nothing ever gets booked twice.
Who can do this: Any staff member, property manager, or board member with access to the property's accounting settings can connect QuickBooks and view sync status. This article describes what the system does automatically once connected.
Record-to-object reference table
| URBI record | Becomes in QuickBooks | Direction |
|---|---|---|
| Invoice | Invoice | URBI → QuickBooks |
| Invoice marked as a credit note, or written off | Credit Memo | URBI → QuickBooks |
| Voided invoice | The matching Invoice is voided in QuickBooks | URBI → QuickBooks |
| Approved expense | Bill | URBI → QuickBooks |
| Voided expense | The matching Bill is deleted in QuickBooks (QuickBooks Bills have no "void" state) | URBI → QuickBooks |
| Payment received and recorded in URBI | Payment | URBI → QuickBooks |
| Refunded or partially refunded payment | The existing Payment record in QuickBooks is updated to reflect the refund | URBI → QuickBooks |
| Payment applied from an existing credit balance | The existing Payment record in QuickBooks is updated | URBI → QuickBooks |
| Billing account (payer) | Customer | URBI → QuickBooks |
| Vendor | Vendor | URBI → QuickBooks |
| Journal entry (manual entries, billing-engine postings, late fees, adjustments, and similar) | Journal Entry | URBI → QuickBooks |
| Journal entry tied to paying an expense | Bill Payment | URBI → QuickBooks |
| Refund journal entry, cash-back method | Refund Receipt | URBI → QuickBooks |
| Refund journal entry, credit-on-account method | Credit Memo | URBI → QuickBooks |
| Refund journal entry on the vendor/expense side | Vendor Credit | URBI → QuickBooks |
| Journal entry voided with no linked invoice/expense/payment | A new, separate reversing Journal Entry (the original stays on the books, untouched) | URBI → QuickBooks |
| Amenity or event booking payment | An Invoice plus a Payment (and a small residual Journal Entry if needed) | URBI → QuickBooks |
| Chart of accounts (GL accounts) | Account | Reference only - used to check that a posting has a valid QuickBooks account behind it; not actively created or edited by the sync |
| A Payment entered directly in QuickBooks against a synced Invoice | A matching payment record in URBI | QuickBooks → URBI (pull-back) |
| A Bill Payment entered directly in QuickBooks against a synced Bill | The matching URBI expense is marked Paid | QuickBooks → URBI (pull-back) |
Only two things pull back from QuickBooks into URBI: payments against invoices, and bill payments against bills. Everything else is push-only, generated in URBI and sent out.
What does NOT sync
- Year-end close journal entries. These are deliberately excluded and never queued.
- Draft invoices, non-approved expenses, and any record still in a non-final state. Nothing syncs until it reaches an approved/posted state in URBI.
- Properties that are not on the PREMIUM plan. If a property is downgraded while still connected, it simply stops accruing new syncs - nothing already sent is undone.
- Properties with no active QuickBooks connection, or a broken one. Sync work pauses until the connection is active again; see QuickBooks Notifications You Will Receive for what happens when a connection breaks.
- A journal entry that touches a general ledger account with no QuickBooks mapping. Rather than guessing or posting to the wrong account, this is held as "Unmapped" and shown in the sync console for a staff member to fix the account mapping.
- Unusual QuickBooks-side edits pulled back, such as a deleted or voided payment, an edit to a payment that was already applied, a bill payment that spans multiple bills, or a partial bill payment. These don't get silently applied - they're written to a review list ("drift") in the sync console instead of guessed at.
The no-double-book guarantee
The integration is built so the same financial event can never be booked twice between URBI and QuickBooks, in either direction. In plain terms:
- QuickBooks-originated records don't bounce back. When a payment or bill payment is entered directly in QuickBooks and pulled back into URBI, URBI tags that record as having come from QuickBooks. The journal entry URBI would normally generate for a new payment is automatically held back for that record, because it already exists in QuickBooks - sending it again would create a duplicate.
- A journal entry doesn't duplicate its own object. When a journal entry is directly linked to something that's already being sent to QuickBooks as its own object - an invoice, a bill, or a payment - the journal entry itself is held back. The invoice, bill, or payment carries the financial detail into QuickBooks; the journal entry would just be the same numbers a second time.
- Retries never create duplicates. Every sync attempt carries a stable request identifier that's reused if the system automatically retries after a hiccup (a QuickBooks timeout, for example) or if staff manually click "Retry" in the sync console. QuickBooks recognizes the repeat request and will not create a second copy of the object.
- Nothing fails silently. Every sync attempt lands in one of a few clearly visible states in the sync console: Completed, Suppressed (deliberately held back to prevent a double-book), Unmapped (needs an account mapping fix), Failed, or Retrying. There is no "it just didn't sync and nobody knew" state - a failed sync is always visible and, for most failure types, notifies staff (see QuickBooks Notifications You Will Receive).
Good to know
- Editing an already-synced Invoice, Customer, or Vendor in URBI only triggers a new QuickBooks update if something material actually changed. If nothing changed, the sync recognizes that and does not make an extra API call.
- Amenity and event booking transactions route through a small bundle (Invoice + Payment, occasionally plus a residual Journal Entry) rather than a single object, so the underlying booking's own journal entry is always held back to avoid a duplicate.
- If you ever see a synced record you don't recognize the shape of in QuickBooks, check the sync console first - every push and pull is logged there with its outcome.