Skip to main content

🏦 Onboarding: Unit History & Bank Imports

Why import order matters, how Vlge matches deposits to owner payments, the guards that stop double counting, and how to fix it when income looks wrong

This is the deep-dive companion to Importing Unit Ledger History. It explains how bank deposits and owner payments relate to each other in the books, why the order you import them in can make a difference, what Vlge now does automatically in every order, how the "matching engine" decides what belongs together, and what to do when the numbers do not look right.

If you only read one section, read The One Rule and if a second, Tips for a smooth import.


⭐️ The One Rule: one cash debit, one income recognition

The same dollars of Owner money can arrive in Vlge from three directions:

  1. The Bank side: A deposit shows up on your bank feed or bank CSV import. If you categorize it straight to an income account (Dues Income, Assessment Income, etc.) Vlge posts Debit Cash / Credit Revenue.

  2. The Unit side - Charges: A dues charge on a unit posts Debit Accounts Receivable / Credit Revenue. This is where income is supposed to be recognized.

  3. The Unit side - Payments: An owner payment (a receipt) on a unit posts Debit Cash / Credit Accounts Receivable. This relieves what the owner owes and records the cash coming in.

Directions 1 and 3 both debit cash. Directions 1 and 2 both credit revenue. If the same real-world deposit gets recorded by the bank side and by the unit side without being linked, you double the cash and double the income. If it is recorded by neither, income is understated.

The books are right when every real deposit produces exactly one cash debit and every dollar of dues produces exactly one revenue credit. Everything in this article exists to make that true regardless of which side you enter first.


👉 Which order should you work in?

You can bring in the unit ledger and the bank in either order. Vlge links the two sides for you in every case; the order only changes how much you review along the way.

Order you work in

What Vlge does

Where you finish up

A. Unit ledger first, then bank (recommended)

Payments post Debit Cash (the Deposit-to account you choose) / Credit A/R. When the bank rows arrive, Financial Inbox offers them as matches to those receipts. Confirming a match links the bank row to the existing entry - no new cash debit. If you import a bank CSV with income categories, deposits that line up with recorded receipts are held back from categorization and left for Confirm Match.

Financial Inbox → Confirm Match (or Confirm exact matches for the whole batch).

B. Bank first and categorized to income, then unit ledger

The unit ledger import looks for deposits already booked as income that the incoming payments explain. It adopts them: the deposit's credit moves from Revenue to A/R, the bank stays debited once, and income is recognized once (from the charges). Payments that cannot be paired are parked in Undeposited Funds and a Reconcile income deposits task opens.

Review the adoption banner in the import preview, then clear the Reconcile income deposits card in Financial Inbox.

C. Bank first but left uncategorized, then unit ledger

Same as A. The bank rows wait in Financial Inbox as match deposit cards; once the receipts exist they are offered as matches.

Financial Inbox → Confirm Match.

All three orders end at the same GL. Order A takes the least review because matching a bank row to an existing receipt is a one-click confirm; order B asks you to review adoptions in the preview and possibly reconcile leftovers afterward.


👉 Before you begin - checklist

  • Properties exist. Rows match on street address.

  • Charge types are set under Billing Settings so the type column maps cleanly.

  • Auto-pay is paused. Importing pending charges can otherwise trigger autopay against them.

  • Know which bank account the checks went into. In Full history mode the importer asks for a Deposit to account. Pick the operating account the owners' payments were actually deposited into. Payments that are adopted onto an existing deposit ignore this and use that deposit's account; payments with no deposit use it.

  • Check the deposit match window. Financial Inbox → Settings → Deposit match window (default 14 days, 1-60). The same window is used by the unit ledger adoption and by inbox matching. Widen it if your treasurer batches checks for several weeks; narrow it if you have many identical amounts close together.

  • Decide on Opening Balances versus history. If an Opening Balances entry already covers cash and A/R for the period, use Subledger only mode. Never put the same dollars in both.

  • Do not reconcile the bank for the import period yet. Once a bank row is checked off in a finalized reconciliation, it cannot be adopted or re-matched. Import first, reconcile after.

  • Make sure the period is not closed. Deposits dated in a closed accounting period are skipped by adoption.


👉 How matching works during the unit ledger import (order B)

This runs automatically in Full history - post to GL mode whenever the file contains payment or credit rows. It does nothing in Subledger only mode.

Which deposits are eligible to be adopted

A journal entry is a candidate when all of the following are true:

  • It is posted and dated within the payment dates in your file, padded by the match window on both sides.

  • It has exactly two lines: a debit to a cash account (any bank or cash-equivalent account) and a credit to a Revenue account. Split deposits, deposits with a fee line, and entries touching other accounts are not touched.

  • It came from a bank feed, a bank CSV import, or a manual journal entry - not from an owner payment, a deposit batch, a Stripe payout, or platform billing.

  • It is not already linked to an owner payment or a deposit batch.

  • Neither line has been checked off in a bank reconciliation.

  • Its date is not in a closed period.

How payments are grouped under deposits - the three tiers

The pairing runs in three passes. Anything paired in an earlier pass is no longer available to a later one.

Badge in preview

Rule

Typical case

Exact amount, same day

One payment and one deposit with the same amount on the same date. If several identical pairs exist that day they pair in file order.

Owner's Zelle or bill-pay deposit, one per owner.

Exact amount in window

Same amount within the match window, and it is the only candidate on both sides. If two $250 payments could go with one $250 deposit, neither is paired here.

Check received on the 3rd, deposited on the 9th.

Sum of payments in order

Deposits are taken oldest first. For each, Vlge walks the still-unpaired payments dated from (deposit date minus the window) up to one day after the deposit, oldest first, adding them up until the running total equals the deposit - the bookkeeper's check-log rule. If the running total overshoots, it looks for the earliest combination of those payments that sums exactly to the deposit instead.

A $2,301.24 Venmo sweep or a stack of checks deposited together.

Payments that no tier could place are leftovers. Deposits that no tier could fill are unclaimed and stay as income.

Important: which payments land under which deposit only affects the bank-reconciliation trail. The GL outcome is the same whichever grouping is chosen, as long as each payment is adopted somewhere - adopting a deposit moves its credit from Revenue to A/R; the unit-level detail lives in the unit ledger. That is why the third tier is allowed to group aggressively. Review the preview, but do not lose sleep over two identical $100 payments being swapped.

What you see in the preview

  • An amber banner: "N deposits already recorded as income will be matched to M payments", with the window shown. Each group lists the journal entry number, date, amount, tier badge, the bank account and description, the revenue account it is currently in, and the file rows that will be adopted onto it.

  • Each group has a checkbox. Untick a deposit to leave it as income. Its payments then post to Undeposited Funds instead and the preview refreshes.

  • Below the groups: "N deposits in this window had no matching payments and will stay as income". Interest, dividend, and other non-owner deposits often appear here - that is correct, leave them.

  • A second banner if there are leftovers: "N payments totaling $X could not be paired with a deposit. They will post to Undeposited Funds (not the bank) and a Reconcile income deposits task will open in the Financial Inbox."

  • Per-row badges in the table: Matched to deposit JE #N (no new cash debit) or Undeposited Funds.

  • The GL impact card shows two extra figures: Reclass deposits to A/R (adopted payments, no new cash) and Dr Undeposited Funds / Cr A/R (parked payments).

What the import posts

  • Adopted payment: the existing deposit entry is reclassed - the Revenue credit becomes an A/R credit (memo notes the adoption). The payment is created on the unit, applied to its charges, linked to that deposit, and marked deposited to that bank account. No new cash debit.

  • Unpaired payment: Debit Undeposited Funds / Credit A/R at the payment date. The payment is on the unit ledger but not yet tied to a bank deposit.

  • Payment with no candidate deposits in the window: Debit the Deposit-to account / Credit A/R.


👉 The Reconcile income deposits card (Financial Inbox)

This card opens after an import that had leftovers or unticked deposits. It shows two lists side by side: Deposits recorded as income (the unclaimed cash-to-revenue entries) and the parked payments sitting in Undeposited Funds. A header tells you which way it leans: Deposits exceed receipts - record the remainder as income, or Receipts exceed deposits - write off or void the excess.

Actions:

  • Match. Pick a deposit, tick the payments it covered (Vlge pre-selects a combination that adds up when it can find one). Confirming reclasses the deposit from Revenue to A/R and moves the payments from Undeposited Funds to that bank account.

  • Match and keep the remainder as income. If the ticked payments are short of the deposit, the difference stays in the revenue account. Use this when a deposit included something that is not an owner payment (a clubhouse rental, a late fee paid in cash that was never charged).

  • Leave JE #N as income. Dismisses a deposit from the card. Nothing posts; it simply stays as income.

  • Write off. When you have more recorded payments than deposits (a payment in your previous system that never actually hit this bank), select the payments and write them off to a Revenue, Expense, or Equity account of your choice. The payments stay on the unit ledger; the write-off entry clears Undeposited Funds.

  • Void. Removes one payment from the owner's ledger, reopens its charges, and reverses its journal entry. Requires a reason. Use when the file row was simply wrong.

  • Undo. Every action on the card is listed in its history and can be undone: the deposit goes back to Revenue, the payments return to the card, and links are removed (reversals are posted where an entry cannot be deleted).

If you see "No combination of the listed payments adds up to this deposit", tick the payments by hand and use the remainder option for the difference.


👉 How matching works in Financial Inbox (orders A & C)

Every bank row that is not yet explained becomes a match deposit card. Vlge scores candidate receipts on a 0-100 scale using amount, date distance inside the match window, payer name or memo similarity, and whether the receipt is already marked deposited to that account. What the score means:

  • 100 - exact amount, same date, single receipt, nothing else competing. Eligible for bulk confirm.

  • 60 and above - a strong match. Vlge will refuse to let the row be categorized to income while a strong match exists (see Guards below).

  • Multi-payment candidates (several receipts that sum to the deposit) are shown but capped below the bulk-confirm bar unless something corroborates them, so they always need a human click.

Actions

  • Confirm Match on a single card. Links the bank row to the receipt(s). If the receipt was in Undeposited Funds, a collection entry moves it to the bank; if the receipt already debited that bank, nothing new posts and the bank row simply claims the existing entry.

  • Confirm exact matches (button in the inbox header). Confirms every open deposit card whose top candidate scores 100, is a single resident receipt, has the same amount and date as the bank row, and has no other candidate with the same amount. It reports how many were confirmed and lists the skipped ones with the reason. Anything skipped is left for you to handle individually.

  • Select several receipts for one deposit. The selection bar shows the running total and how far short you are.

  • Record the remaining $X as income. When the selected receipts are short, tick this box and choose a revenue account. Vlge posts the receipts as a match and books only the difference to income, dated the bank row. It never books more than the deposit amount.

  • Undo match. Unlinks the bank row, reverses any remainder-to-income entry, and returns the card to open. Refused if any of the entries involved have since been checked off in a reconciliation - undo the reconciliation first.


👉 Guards that stop double counting - and what the messages mean

Message

What it means and what to do

"This deposit matches N recorded resident payments (X% confidence). Use Financial Inbox → Confirm Match instead of categorizing it…"

You tried to categorize a bank row to income, but receipts on the unit ledger already explain it. Open the row in Financial Inbox and confirm the match. If the match is genuinely wrong (for example, the receipt belongs to a different deposit), match the receipt to the right row first and then categorize this one.

Bank CSV import: "N deposits line up with resident payments already on the ledger… Confirm them in Financial Inbox"

Your CSV had income categories on those rows, but Vlge held them back rather than post a second cash debit. Nothing is lost - the category is saved on the row. Go to Financial Inbox and confirm the matches; the rows will be explained by the receipts instead.

"This bank row was already checked off in [reconciliation]…"

The row is inside a reconciliation. Categorizing it again would record the cash twice. If the original treatment was wrong, undo it from inside that reconciliation.

"This bank row is dated…, inside a period that has already been reconciled and finalized…"

The statement period is finalized. Reopen the reconciliation if the row truly needs to change; otherwise the difference belongs in the next period.

"This transaction is dated…, on or before the Opening Balances cutover…"

The cash for that date is already inside your Opening Balances entry. Do not categorize it; mark it as pre-cutover or ignore it.

"This bank line is money movement the platform originated…"

Resident ACH dues, refunds, vendor ACH, Stripe payouts and platform billing already have a closed-loop record. Use Confirm Match. If nothing is offered, the batch may still be settling - wait a day.

"Journal entry #N is no longer a plain income deposit and cannot be adopted."

Between preview and import someone edited, reconciled, or linked that deposit. Re-analyze the file; the payments will be parked in Undeposited Funds instead and you can match them from the Reconcile card.

"The selected payments already cover this deposit."

You ticked "record the remainder as income" but there is no remainder. Untick it and confirm.


👉 Tips for a smooth import 👈

  1. Unit ledger before bank. If you have the choice, import the unit ledger history first, then connect the bank feed or import the bank CSV. Matching a bank row to an existing receipt is a single click and needs no reclass.

  2. If the bank is already categorized, leave it. Do not uncategorize deposits by hand before importing the unit ledger. The import will adopt them. Hand-uncategorizing just creates more inbox cards.

  3. Use the real payment date, not the deposit date. The chronological tier looks back from the deposit by the window and forward one day. A check dated after the deposit it was part of will not be grouped.

  4. One row per check. Do not pre-total a unit's payments into one row for the month if the bank saw separate deposits, and do not split one check into several rows. The tiers match on exact cents.

  5. Fees break exact matching. A Venmo or card deposit that arrived net of a processing fee will not sum to the gross payments. Either record the payments net, or let the deposit stay unpaired and use Match with the fee recorded separately as an expense.

  6. Set the deposit match window before you import. Financial Inbox → Settings → Deposit match window controls how many days apart a payment and a bank deposit can be and still count as the same money (default 14). Look at the preview. If many payments show as "could not be paired with a deposit" and the reason is simply that your treasurer holds checks for a few weeks before depositing them, raise the window (for example to 30) and click Re-analyze. The pairing runs during preview, so changing the window after the import has run will not fix that batch.

  7. Read the unclaimed list. Interest, dividends, insurance refunds and vendor rebates belong there. If an obvious owner deposit is unclaimed, look for a payment row with a typo in the amount.

  8. Import in date-ordered batches (for example, one fiscal year at a time). Duplicate rows across batches are detected and skipped unless you opt in, but smaller previews are easier to review.

  9. Reconcile the bank last. Import, clear the Reconcile income deposits card, confirm inbox matches, then run Bank Reconciliation from a recent statement date. Reconciling first locks rows out of adoption.

  10. Check the report, not just the ledger. After the import, open the Income Statement on a cash basis for the imported period. Operating Income should equal what actually landed in the bank from owners plus other income - no more, no less.


🛟 Troubleshooting

Symptom

Likely cause

Fix

Operating Income shows $0 or far too low on the cash-basis Income Statement even though deposits are categorized to income

The deposits landed in an account whose type is not Revenue (for example an "Other Income" account set up under Equity, or a liability), or the report's date range does not cover the deposit dates.

Check the account type in the Chart of Accounts and the report date range. Re-categorize the rows to a Revenue-type account if needed.

Income is roughly double what came in

Bank deposits are categorized to income and unit charges posted revenue, with the payments never linked to the deposits - usually because deposits were unticked in the import preview, or a bank row was categorized to income even though a receipt already covered it.

Open Financial Inbox. If a Reconcile income deposits card exists, match the deposits to the parked payments. If the payments posted straight to the bank, undo the categorization on the bank row and Confirm Match to the receipts instead, or undo the import from Recent Imports within 24 hours and re-run it.

Cash balance is higher than the bank statement

Same deposit debited twice: once from bank categorization, once from a receipt.

Run Bank Reconciliation for the month; the unmatched pairs will show. Undo the categorization on the bank row (if not reconciled) and Confirm Match to the receipt instead.

Undeposited Funds has a large balance after import

Those payments could not be paired with a deposit (leftovers), or you unticked their deposits.

Clear the Reconcile income deposits card: match, record remainder, write off, or void. Undeposited Funds should return to zero (or to genuinely un-deposited checks).

A deposit I expected to be adopted stayed as income

One of the eligibility rules failed: it is reconciled, in a closed period, has more than two lines (a fee or a split), is already linked to a payment or batch, is outside the padded window, or no payments sum exactly to it.

Open the journal entry and check lines and reconciliation status. For fee deposits, match from the Reconcile card and record the fee as an expense. For date issues, widen the window and re-analyze.

A deposit was adopted with the wrong payments

Several identical amounts in the window; the tiers picked deterministically in date and file order.

The GL is still correct. Only the reconciliation trail differs. If it matters for the bank rec, undo the group from the Reconcile card history and re-match by hand.

Interest or dividend entries appear in the unclaimed deposits list

They are two-line cash-to-revenue entries, so they are technically candidates.

Leave them. They are correctly income. Use "Leave as income" on the Reconcile card if they show up there.

Confirm exact matches skipped most cards

The bar is deliberately high: score 100, one receipt, same amount and date, no other receipt with the same amount. Dues where many owners pay the same amount rarely qualify.

Work the skipped list card by card. Payer names and memos on the bank row help the score; encourage owners to include their address in the memo.

Bank CSV import reports fewer categorized rows than my file had

Income-categorized deposits with a strong receipt match were held for Financial Inbox.

Expected. Confirm the matches in Financial Inbox; the rows keep their saved category for anything that turns out not to match.

Undo match is refused

One of the entries involved has been checked off in a bank reconciliation since the match.

Undo it inside that reconciliation first, then undo the match.

Owner shows a credit balance after import

Charges were imported as paid and payment rows were included for the same dollars (Approach A and B mixed), or a payment row is duplicated.

Undo the import within 24 hours, fix the file, re-import. See Deleting Recent Financial Imports.

Preview shows "Possible duplicate within this file" or "matches a record already imported"

Same unit, date, type and amount seen twice.

In-file duplicates still import - remove one if it is not a real second payment. Cross-batch duplicates are skipped unless you opt in.


Glossary

  • Receipt / owner payment - a payment recorded on a unit ledger. Posts Debit Cash (or Undeposited Funds) / Credit A/R.

  • Cash-to-revenue deposit - a bank row categorized straight to an income account. Posts Debit Cash / Credit Revenue.

  • Adopt - reclass a cash-to-revenue deposit so its credit goes to A/R instead of Revenue, and link the owner payments that explain it. The bank debit is kept; no second cash entry.

  • Undeposited Funds - the holding account for receipts that have not been tied to a bank deposit yet.

  • Match window - how many days apart a payment and a deposit may be and still be paired. Financial Inbox → Settings. Default 14.

  • Strong match - an inbox candidate scoring 60 or higher. Blocks categorizing the same row to income.

  • Remainder to income - when matched receipts are short of a deposit, the difference is booked to a revenue account you choose.

  • Write-off - clears parked receipts that will never be matched to a deposit, to a Revenue, Expense or Equity account.


🛟 Need more help? Just ask!

Did this answer your question?