Types of Accounts Receivable Items in VRTrust and How to Handle Each
Accounts Receivable should, in a clean set of books, contain almost nothing at any given time: payments post to AR briefly and clear out as soon as they're matched to a reservation. When AR carries a growing list of items month over month, it's usually one of a handful of recurring causes. This guide walks through each one.
To view your Accounts Receivable balance, navigate to:
Reports > Guest Balances Report > Departed
Note: Note: VRTrust has no separate "invoice" object the way QuickBooks does. A reservation's financial lines are the receivable.
Payments (deposit transactions) post against a reservation and are cleared when they're matched to that reservation's financial lines / journal entries.
Two of the items below (Duplicate Payments and Payments for Completed Stays That Haven't Cleared) correspond to system-level checks VRTrust already runs and surfaces as issues — via GET /teams/issues and in-app data-quality banners. You don't have to eyeball everything manually; check for these codes first (e.g., by asking an MCP-connected AI assistant to pull open issues for the team), then work the list below.
What Should Normally Be in AR
Advance deposits for future reservations. A guest has paid for a stay that hasn't happened yet. This is expected and will clear naturally as the stay occurs and the payment is applied.
Everything else in AR at month-end is worth investigating. The items below are listed roughly in order of how often they show up.
AR Items To Investigate:
1. Unmatched (Unapplied) Payments
What it looks like: A payment sits in AR against a guest or reservation, but it was never matched to that reservation's financial lines. It shows as a payment line with no attached reservation.
Why it happens: Most often, a bank-feed transaction was reconciled directly against the reservation's revenue line instead of against the actual payment/deposit transaction, leaving the original deposit unmatched and orphaned in AR.
It can also happen when a payment was processed manually in Stripe or Airbnb (e.g., as part of a resolution) outside the normal PMS flow. In that case there's no source data to auto-link it to a reservation.
How to resolve it:
Identify the reservation the payment belongs to (guest name, dates, confirmation code), then:
If it was a normal synced payment that simply hasn't matched yet, give it up to 24 hours — VRTrust's matching process often resolves this automatically once the reservation and payment are both present.
If it's still unmatched after that, or if it was a manual/off-platform payment, record the deposit directly against the correct reservation (rather than leaving it as a standalone line). This clears it from AR.
If the reservation it belongs to has since been canceled, don't try to match it to the original (now-superseded) revenue lines. Instead follow the cancellation adjustment workflow so the retained payment is recorded as owner or PM revenue per your cancellation policy (see item 4 below).
2. Duplicate Payments
What it looks like: Two payments show against the same guest or reservation for the same amount.
Why it happens: A deposit was matched to a reservation directly in bank reconciliation, and the reservation payment automation/sync also created its own deposit transaction for the same funds, so the same money is represented twice.
System check: This is a named, system-detected issue [duplicatedPayments]. It fires when multiple recent payments share a source reference across connections, and its context includes the specific payment IDs, dates, and connection names involved, so you don't have to hunt for the match manually. Pull it via GET /teams/issues.
How to resolve it:
Open the reservation and review each deposit/payment line.
Identify which one is the duplicate, typically the one posted directly against the bank account rather than through the processor's normal payment/clearing flow (Stripe, Airbnb, etc.).
Delete the duplicate transaction, keeping the one that matches how the processor actually settled funds.
3. Payments for Completed Stays That Haven't Cleared
What it looks like: A reservation has already checked out, but its payment is still sitting in AR instead of having cleared to guest balances or revenue.
Why it happens: This is the one category that shouldn't exist for more than a few days. It usually signals a payment sync/automation that hasn't run for that reservation, or a payment that was received outside the normal processor flow (a check or manual deposit) and never linked.
System check: Related to the reservationPaymentProjectionMismatch warning, which fires when stored reservation payment fields differ from the active deposit journals. Its context lists each affected reservation with the stored vs. corrected paid amount and status, a faster starting point than reviewing reservations one by one.
How to resolve it:
Confirm the reservation's payment status. If a real payment was received but hasn't posted, re-run the relevant payment sync/automation for that reservation so it flows through normally.
If the payment was received manually (check, wire, etc.) and never entered, record it directly against the reservation instead of leaving it as a standalone AR item.
4. Payments Tied to Canceled or Voided Reservations
What it looks like: A payment remains in AR against a reservation that's since been canceled, with the retained amount not yet recorded as recognized revenue.
Why it happens: The reservation was canceled after the original payment was recorded, and no cancellation adjustment was made to reallocate that retained payment to revenue.
System check: cancelledReservationPaidWithoutAdjustment fires when a canceled reservation remains paid without an adjustment, with context listing the reservation ID, confirmation code, and cents paid.
How to resolve it:
Do not try to reuse or edit the reservation's original (now-superseded) financial lines.
Add a reservation adjustment to record the retained amount as cancellation revenue. By default, VRTrust records cancellation revenue to the owner — see Cancellation Revenue to Owners.
If the property manager should keep some or all of that revenue instead:
For a standing policy applied consistently across listings, set up a Cancellation Fee – PM (see Allocate Cancellation Fee Revenue to the Property Manager), which reallocates automatically whenever a cancellation adjustment is added.
For a one-off exception to your normal policy, use a manual fee adjustment on that specific reservation (see Cancellation Fee Adjustments).
For an occasional, non-standard case where PM revenue isn't your default at all, create an unlisted "Other Fee" (e.g., Cancellation Revenue – PM) and apply it manually only when needed.
Once the adjustment is saved, the previously-unmatched payment nets against it and clears from AR.
5. Refund Journal Entries
What it looks like: A journal entry sits in AR representing a processor refund (commonly a Stripe or Airbnb refund tied to a cancellation or resolution).
Why it happens: The refund posts as its own journal entry and needs to be matched against the original payment, it doesn't clear on its own.
How to resolve it:
Find the reservation and review its payment and refund lines together:
If it's a straightforward cancellation, follow the same cancellation adjustment workflow as item 4 above, so the payment, retained revenue, and refunded portion all net out correctly.
If the refund relates to an Airbnb resolution rather than a plain cancellation, follow Adjusting Financials for Airbnb Resolutions or Other Adjustments instead. The correct offsetting account or party may not be a straightforward AR clear-out.
Confirm the reservation's open balance nets to zero and drops off the Guest Balances report once the adjustment is saved.
6. Overpayments and Underpayments on Open Guest Balances
What it looks like: A departed guest shows a non-zero balance. Either they paid more or less than the reservation total.
Why it happens: Extra charges (an add-on, a baby crib, a resolution) were collected outside the original invoice, or a partial payment was never followed up on.
System check: Related to the reservationGuestTotalsMismatch warning, which fires when a reservation's AR journals don't match the reservation total, with context showing the AR total, reservation total, and the difference.
How to resolve it:
Follow the Guest balances review: Adding financial adjustments workflow
If the extra/missing amount is for a known specific charge (e.g., cleaning), add the adjustment directly from that line item.
If it isn't tied to a specific line (e.g., a baby crib fee with no matching line), add a general reservation adjustment instead.
Confirm the balance clears from the departed section of the Guest Balances report after the adjustment is saved.
Monthly AR Review Checklist
Connect an AI Assistant to the VRTrust MCP and tell it to check open
issuesfor the team (duplicatedPayments, reservationPaymentProjectionMismatch, cancelledReservationPaidWithoutAdjustment, reservationGuestTotalsMismatch) before doing a manual line-by-line review.Run the Guest Balances Report as of the last day of the month under review, filtered to Departed.
Confirm every remaining item is either a genuine advance deposit for a future stay, or an open guest balance you're actively resolving. Nothing else should still be sitting there.
Work through unmatched payments, duplicates, cancellation adjustments, and refund journal entries using the steps above before closing the month.
Cross-check the cleared total against the Trust Reconciliation Report, which surfaces accounts receivable as part of the overall trust balance.