This article answers common questions property managers ask about the bulk fees and leases upload, and the bank debit agreements that can go with it. If a question below points you to another...
Last updated
This article answers common questions property managers ask about the bulk fees and leases upload, and the bank debit agreements that can go with it. If a question below points you to another article, that article covers the topic in full detail; this page only gives you the short answer.
If I upload the file, has anything changed yet?
No. Uploading a file only reads it into the wizard so you can review and match it against your units and residents. Nothing is written to your property's records until you press Commit on the final settings step, and every step along the way tells you plainly that nothing is saved until you confirm it. See Uploading, step by step.
Can I close the drawer and come back later?
Yes. Each choice you make, a unit match, a payer pick, an uploaded file, is saved as you make it, so closing the drawer does not lose your progress. Reopening the wizard from Bulk Actions returns you to the same batch. Once a batch is committed, the Send card on the Bulk Actions tab always shows your most recent committed batch, so you reach the same place every time you come back.
I committed by mistake. What now?
Committing creates real leases, billing accounts and charge schedules, and the wizard has no button to undo that. When residents were asked to sign, committing does not contact anyone by itself: messages wait on the Send card until you choose to send them, so nobody has heard about it yet. When you declared signed paper agreements, each resident gets one setup email automatically as soon as you commit, so they may already have heard about it. If you need a record that was already created to be reversed or corrected, contact your URBI administrator. See After you commit.
Can I recall a message I already sent?
No. Once a message is sent it cannot be recalled. If you are not certain everything is right, use Send on a date instead of Send now, since a scheduled send can still be cancelled before it goes out. See Sending the messages.
Will anyone be emailed twice if I press send again?
No. A person who has already been messaged for a batch is not messaged again, even if you press send again on the same batch. Anyone added to the property, or committed, after the batch was already sent needs a new batch of their own. See Sending the messages.
What happens if my browser closes in the middle of a commit?
Nothing is lost, and nothing is committed twice. If you reopen the batch, it tells you either that it kept committing while the drawer was closed, or, after a genuine crash, that it picked up again from exactly the row it had reached. There is also a "Navigate away safely" button so you can close the drawer on purpose while a commit keeps running in the background. See After you commit.
Will a resident be charged straight away?
No. Charging follows the fee start date and billing day you set on the Launch settings step, not the moment you commit. For bank debit rows specifically, no money is taken until the agreement is either signed by the resident or recorded under a staff declaration, and even then the first debit follows the schedule you set. When you declare signed paper agreements, committing creates the first bill, due on the first debit date you chose, and the bank file for that date collects it. No invoice email is sent for that bill. See Launch settings and dates.
Why is my fee not prorated for a part month?
Fees are never prorated in this wizard. Instead you choose one of two start options on Launch settings: "Charge the first period on the start date" bills the full period even if the date falls mid cycle, or "Start at the next billing date" skips the partial period and begins on the next full billing date. A backdated start is not offered either way. These start options are not shown when you declare signed paper agreements, because the fee start date is then the first debit date. See Launch settings and dates.
Can I backdate a fee start date?
No. The fee start date has to be a real, upcoming date that lands on the property's billing day, and the wizard does not offer a backdated start. See Launch settings and dates.
What does Update do to a unit that already has a lease, and does it touch past invoices?
Choosing Update changes the monthly fee amount from the date you set. The resident, the other lease dates, and every invoice already issued are left exactly as they were. Choosing Refuse instead leaves the current active lease untouched and that row is skipped. See Matching units and payers.
Why does the amount have to be written in cents?
The fee and rent columns take a whole number of cents rather than a dollar amount with a decimal point, for example 41250 for $412.50. Writing amounts this way keeps the money exact, a cell with a decimal point or with letters in it is rejected. See Preparing your fee and lease file.
Do I have to collect bank details at the same time as the fees?
No. Fees and bank debit details run on two separate tracks inside the same wizard. You can upload just the fee and lease file and commit it on its own, then bring in a bank details file in a later batch, or you can add the bank details file during the Review step of the same batch before you commit. You can also upload bank details on their own, choosing bank details only, for units whose fees already run. See Preparing your bank details file.
Can I use the sign request for some people and the staff declaration for others?
No. You choose one consent path for the whole batch on the Launch settings step, and it cannot be split row by row. If you genuinely need both approaches, run two separate batches. See Bank debit agreements explained.
Why does my resident's first payment date say "if signed by" instead of a real date?
This means their agreement is still waiting on their signature. Until they sign, the date shown is only a projection based on the signing deadline, phrased "If signed by [date], first payment [date]". Once the resident signs, their row updates to a real, confirmed date. See What your residents see.
A resident signed late. What happened to their first payment?
If a resident signs after the projected deadline, that one charge is paid another way and their bank debits begin the following month instead. They see their real first payment date as soon as they sign, and it may not match the date they were originally shown. See What your residents see.
What if a resident never signs?
Nothing is debited from their bank account until they sign. The fee itself does not wait on a signed bank debit agreement, so it still has to be paid another way until the resident signs. From the Send card you can press "Remind unsigned" to email everyone in the batch who has not yet signed, anyone reminded in the last three days is skipped, and expired links are replaced with new ones valid for 14 days. See Sending the messages.
Someone already pays that unit by bank debit. Why is my row refused?
A billing account can hold only one active bank debit agreement at a time, and each payer can hold only one agreement of their own. If the billing account already has a live agreement, or a different person already pays it by bank debit, your row is excluded from bank debit setup and there is no override for it in the wizard, the fee row for that unit still commits normally. Cancel the existing agreement from that person's own payment settings first, then upload the row again. See Errors: bank debit rows and conflicts.
Do I have to attach the paper agreement?
No. Attaching a signed paper agreement is optional on both consent paths and never blocks anything. If you do attach one, it is saved to that unit's PAD Agreements folder, staff only. See The staff declaration.
The person in my file is not in URBI yet. Can I still import their row?
Yes. On the Payer step, choose "Invite [name]" to add them as a new invited person and make them that row's payer. Nobody is created or emailed at that point. In a batch where residents are asked to sign, nothing happens to them until you send the messages. If you declared signed paper agreements, it happens when the import commits. See Matching units and payers.
When is an invited person actually created and emailed?
In a batch where residents are asked to sign, an invited person is created, and only then emailed, at the moment you send the messages for that batch. Until then nothing exists for them and nobody has contacted them. If you declared signed paper agreements for the batch, the invited payer is billed when the import commits, and their setup email goes out automatically at that point. See After you commit.
Why can I not choose this person as the payer?
The person picker greys out anyone who cannot be a payer and tells you why: dependents cannot be payers, a person who no longer lives at the unit cannot be chosen, and an archived invited person cannot be chosen either. Pick a different person on the same unit instead. See Matching units and payers.
Why must the messages go out ten days before the fee start date?
When residents are asked to sign, bank debit messages need at least ten days' notice before the fee start date, so residents get proper advance warning before their bank account is debited. If the fee start date is already less than ten days away, the communication date field is blocked until you move the fee start date later.
When you declare signed paper agreements, there is no communication date. Instead, the first debit date must be at least ten days after the date residents were told. When you upload fees only, with no bank debit rows, there is no ten day rule at all. See Launch settings and dates.
I can upload fees but not bank details. Why?
Uploading fees and uploading bank debit details use two separate permissions, on purpose. Having the leases or payments permission is enough to unlock fees, while bank debit details specifically need the payments permission. Ask a property administrator to grant it if the bank debit button stays locked for you. See Before you start.
Someone else on my team is working on the same batch. What happens?
The wizard checks that the batch has not changed since you last loaded it. If a colleague saved a change while you had the same batch open, your next action is refused with a message telling you to refresh and try again, rather than silently overwriting their work. See Errors: someone else changed it.