How bank debit agreements work in a bulk upload

This article explains how a resident's permission to be debited is collected when you upload fees and bank details in one batch. It is for property managers, building staff and board members who are about to run a batch, or who are looking at the bank debit list and wondering what a status or a date means.

What a bank debit agreement is

A bank debit agreement is one person's written permission for the property to take their monthly fee straight out of their bank account, on a set day, without asking again each month. The formal name for this in Canada is a "pre-authorized debit". This article set calls it a bank debit agreement from here on, because that is the plain wording used on screen.

Two things have to be true before any money moves. The property must hold the person's bank details, which is what the bank details file gives you. And the property must hold that person's permission, which is what this article is about. The bank details on their own are never enough.

The one choice you make for the whole batch

There are three ways a person's permission is obtained. You choose between the first two ONCE, for the whole batch, on the Launch settings step. You cannot pick one way for some rows and the other way for the rest. There is no per row switch anywhere in the wizard, so it is worth deciding before you start rather than looking for one later.

The block on screen is headed "How will people agree to bank debits?" and says, directly under the heading, "Choose once for this whole batch. This cannot be split row by row."

The third way, set-up invitations, is not part of that choice. It is a separate toggle that runs alongside whichever of the two you picked, and it reaches a different group of people.

The consent block on Launch settings with "Send each person the agreement to sign" chosen: the two options, and the alignment toggle underneath. The alignment toggle only shows for this option. It is hidden when you declare paper agreements.

Path 1: "Send each person the agreement to sign"

The description under this option reads: "Each person gets an email to review their bank details and sign. Nothing is debited until they sign."

This is the path where URBI collects the signature for you, and keeps it.

Here is the whole sequence, in order.

1. On the Review step, you upload the bank details file. Each row is checked the moment it lands. A row that passes is shown back to you masked, as "Institution 003, Transit 12345, ending in 6789", and tagged either "Matched" or "Needs review". The full account number is never shown back to you and is never kept as a file. Nothing has been sent to anyone at this point.
2. On the Launch settings step, you pick this option. Picking it emails nobody. It records which way this batch will collect permission, and nothing else.
3. You press Continue on Launch settings, which saves the settings and commits the batch. For each bank debit row, one agreement is created, in a not yet signed state. On the review list, those rows now read "Awaiting signature", and their date is a projection, phrased "If signed by 3 Oct 2026, first payment 1 Nov 2026".
4. Still, nothing has gone out. On this path, committing creates the agreements and prepares the emails, but it does not send them. The emails wait on the Send card, where you choose Send now or Send on a date.
5. When the messages go out, each payer gets one email. The subject reads "Verify your bank details and sign up for bank debit: ". It carries a link that expires 14 days after it is sent. For security, the link does not open the agreement on its own: the person signs in to the resident portal with an 8 digit code emailed to them, then reviews their bank details and signs.
6. Once a person signs, their row on your list stops saying "Awaiting signature", and the date stops being a projection and becomes a real, confirmed date.
7. To chase the people who have not signed, use Remind unsigned (N) on the Send card. The confirmation explains exactly what it does: "This emails everyone in this batch who has not signed. Anyone reminded in the last 3 days is skipped. Expired links are replaced with new ones valid for 14 days." So a person whose link has run out does not need anything special from you; the reminder gives them a fresh 14 day link.

One thing this path refuses outright. A row whose payer has no email address is refused before any agreement is created, because an agreement nobody can be sent would sit there unsigned forever. The message on that row reads: "This row has no email address, so the payer could never be sent the agreement to sign. Add their email to the file and upload this row again, or choose staff declared consent."

Path 2: "I already hold signed agreements (staff declaration)"

The description under this option reads: "No sign request goes out. You are declaring, on the record, that every row already has a signed agreement."

This is the path for a property that already has signed paper agreements in a filing cabinet and does not want to ask everyone to sign again. In short:

1. You click the option. Nothing is saved yet. A card titled "Signed paper agreements" opens. It reads: "Residents hold signed paper agreements and were told about the first debit on . This is recorded with your name, the time and your device."
2. You choose two dates on that card: "Date residents were told (notice date)" and "First debit date". There must be at least 10 days between them. The rules for both dates are in Choosing your dates and launch settings.
3. When you press Continue, you confirm by typing your full name, under the heading "You are taking responsibility for these bank debits", and you read what you are taking on first. If you cancel, the choice is left exactly as it was, so this path cannot be taken by accident.
4. Every row in the batch is then marked "Declared by staff". No resident is asked to sign anything, and no sign request is ever created.

Declaring changes what the commit does, so it is worth knowing before you press it. When the batch commits, URBI creates each row's lease and charge schedule and its bank debit agreement, with the first debit date you chose. It also bills the first debit right then: the first charge and its invoice are dated and due on the first debit date, and that day's bank file collects the money. The payer is billed whether or not they already have an URBI account. No invoice email is sent for this first bill.

Each payer also gets one setup email, automatically, when the batch commits. You do not press Send for it, and it does not wait on the Send card. It is described in Declaring that you already hold signed agreements.

The responsibility is real and it is stated plainly in that window: "If a resident disputes a debit with their bank, the property is responsible and must produce the signed agreement and written approval."

Because this path carries legal and money weight, it has its own article. Read Declaring that you already hold signed agreements in full before you choose it.

Path 3: "Send set-up invitations"

This one is not part of the two way choice. It is a toggle on Launch settings, labelled "Send set-up invitations", described as "Sent to anyone in this batch with no bank debit row, so they can set up their fee on their own."

Who gets these: the people in your batch for whom you uploaded NO bank details. If a person has a bank debit row, they are handled by path 1 or path 2 and they do not get an invitation. If they have no bank debit row, this toggle offers them the chance to set themselves up.

What the invitation does:

1. The toggle is on by default when the property is able to take bank debits. If the property cannot, the toggle is forced off and cannot be turned on, with the reason shown: "Off because this property cannot accept bank debits yet. No bank account is connected for collections."
2. When the batch's messages go out, those people get an email with the subject "Set up bank payments for your fee: ", which links to the billing area of the resident portal.
3. There, the person sets themselves up. They choose how they want to pay, connect their bank account, see which locations the agreement covers, then read and sign the agreement themselves.

You can see how many of these were prepared in the "Set-up invitations" count tile on the Send card, and open the tile to see exactly who is on that list.

The projected first payment date, and the confirmed one

This is the part people most often misread, so read it slowly.

A date on the bank debit list always names its own basis. There are three things you can see in the First debit date column:

• A plain date, for example "1 Nov 2026". This is a confirmed date. Nothing further has to happen for it to hold.
• A projection, phrased "If signed by 3 Oct 2026, first payment 1 Nov 2026". This is a conditional sentence, not a booking. It is telling you what the first payment WOULD be if that person signs by that day.
• "Not scheduled". The row has no first debit date yet. It resolves once the agreement is signed or declared.

What makes a projection turn into a confirmed date: the person signing. Until they sign, the date depends on when they sign, so URBI will not state it as fact. This is why the two phrasings exist at all. On path 1 you should expect projections, because the property does not yet hold the signature. On path 2 you should expect plain confirmed dates, because the permission is already in hand and the first debit date is the one you chose on the Signed paper agreements card.

The same distinction follows the person through every screen:

• On the Send card, a recipient row reads either "First debit 1 Nov 2026" or "First debit 1 Nov 2026 if signed by 3 Oct 2026 (estimate)".
• On the resident's own signing page, the First payment row reads either "If you sign by 3 Oct 2026, your first payment is 1 Nov 2026." or "Confirmed as soon as you sign".
• The resident is also told what happens if they are late: "If you sign later, that charge is paid another way and bank debits start the following month. You will see your real first payment date as soon as you sign."
• After they sign, if the real date turned out different from the one they were shown, the page says so: "This is not the date shown before you signed, because the first payment date depends on the day the agreement is signed. is your real first payment date."
• If the date moves while the page is open, nothing is signed by accident. The page says "The first payment date changed since this page loaded, so nothing was signed. Here is the new one: ... Review it and sign again."

One more thing to know. If you change the fee start date after the messages have already gone out, the dates people were emailed can no longer match the dates shown in the app, and URBI tells you this before it lets you do it. The confirmation reads "Messages for the fee start date have already been sent. They cannot be recalled." and "The dates shown in the app and on the sign page recompute from live data, so they can now differ from what people were emailed."

The alignment toggle: "Start bank debits on the fee start date"

This toggle belongs to the path 1 option, "Send each person the agreement to sign". It is hidden when you declare paper agreements (path 2). A declared batch does not use it, because you choose the first debit date yourself on the Signed paper agreements card, and the fee start date follows that date.

Under the two consent options sits a toggle, "Start bank debits on the fee start date". It decides what the first debit lines up with.

• On. Everyone's bank debits aim to start on the fee start date you set for the batch, so the fee and the debit begin together.
• Off. As the toggle's own description says, "When off, the first debit lines up with each person's own sign date or declaration date instead." On path 1 that means each person's start depends on the day they personally signed, so two people in the same batch can begin in different months. The words "or declaration date" do not apply on path 1, because nobody declares anything there.

You cannot touch this toggle until you have chosen a consent option. While it is locked, hovering it shows: "Choose how people will agree to bank debits first".

If the batch already has a send booked for a date, changing this toggle cancels that booking, and you are told so: "The scheduled send was cancelled because launch settings changed." You then book or send again.

When the payer does not exist yet

On the Payer step, some rows have no matching person on the unit, and you choose Invite for them. The panel there says it plainly: "Nobody is created or emailed until you send the messages."

That has a knock-on effect on bank debits, and it is deliberate. For those rows:

1. At commit, no person is created, and the bank debit row is parked rather than enrolled.
2. At Send time, things happen in a strict order. The payer is created (or an existing record is adopted) and attached to the billing account as its holder. Any one held invoice is raised. The parked bank debit rows are then enrolled exactly as they would have been at commit, on whichever path you chose. Only then are the messages prepared.

Nothing is lost by this delay. Because enrolment happens before the messages are prepared, a row enrolled at Send time still carries its agreement in the email the person receives, exactly as a row enrolled at commit would have.

A declared batch (path 2) does not wait for you to send. Its first bill is raised at commit for every payer, including a payer who has no URBI account yet, and the send that runs automatically right after the commit creates the invited person and emails their setup notice, in the order described above.

If the payer still could not be created, the row is not discarded either. It is reported on the Send card as "The payer's account has not been created yet" and is retried on a later send. The bank details you uploaded are kept.

The status chips on the review list

The bank debit review list appears on the Review step, and again, read only, on the screen you see when the commit finishes. Its columns are the person and unit, Account, Agreement and First debit date, with a counter reading " still unsigned".

One row on the bank debit review list: a masked account, a status chip, and a first payment date that names its condition.

What each chip in the Agreement column means:

• "Awaiting signature". An agreement was created for this row and the payer has not signed it yet.
• "Declared by staff". The agreement carries your declaration instead of the payer's signature. This is what every row looks like on path 2.
• "Not created". No agreement exists for this row yet.
• "Needs bank details". The staged bank details behind this row were already used and could not be kept, so the row cannot enrol until you supply them again. The row carries its own explanation, "This row's bank details were already used and could not be kept. Upload them again for this row.", and a Re-upload bank details button.
• "Refused". The row is excluded from bank debit setup because of a conflict, most often because that billing account already has a live agreement, or because someone else already pays that account by bank debit. This chip overrides whichever of the four above would otherwise apply. Being refused for bank debit does not stop the fee itself: the refusal text says so, for example "This billing account already has an active bank debit agreement. There is no override for this row; it is excluded from bank debit setup. The fee row for Unit 304 still commits."

You may also see an extra tag, "Replaces an earlier agreement". That is not a status. It tells you this row's agreement supersedes an earlier one for the same payer.

In the Account column, a row reads "ending in 6789" when bank details are held, or "Not on file" when they are not. If you see "Not on file", upload that row's bank details again.

Attaching the paper agreement

Every row on the review list has an optional drop area, reading "Drop the signed agreement here" on a computer, or "Tap to add the signed agreement" on a phone. It accepts a PDF, JPG or PNG file of up to 25 MB.

Four things to know about it:

1. It is optional on BOTH consent paths. You can attach paperwork to a row whose payer is going to sign in URBI, and to a row covered by your declaration.
2. It never blocks anything. Attaching nothing does not stop a row committing, and does not stop a message going out.
3. The file is filed in that unit's PAD Agreements folder. Once it lands, the row reads "Saved to this unit's PAD Agreements folder. Staff only.", which is exactly what it means: residents do not see it.
4. The unit has to be resolved first. If it is not, the upload is refused with "Resolve the unit before attaching paperwork".

If you are taking the staff declaration path, attaching the paperwork here is a sensible habit, because that path asks you to be able to produce the signed agreement on request. It is still optional, and attaching a file does not move the responsibility off the property.

Related articles

• Uploading fees, leases and bank debit agreements in bulk: overview
• Preparing your fee and lease file
• Declaring that you already hold signed agreements