Declaring that you already hold signed agreements

This article covers one option in the bulk upload wizard: "I already hold signed agreements (staff declaration)". It is for property managers, building staff and board members deciding whether to use it. It is written to leave nobody in doubt about what taking this option means for the property, so read it in full before you choose.

What this option is for

When a batch contains bank debit rows, the Launch settings step asks how the people in that batch will give their permission to be debited. One of the two answers is this one, described on screen as: "No sign request goes out. You are declaring, on the record, that every row already has a signed agreement."

It exists for one situation: you already hold a signed paper bank debit agreement from every single person in this batch, collected outside URBI, and you do not want to ask those people to sign again.

It is the wrong option in every other case. If even one person in the batch has not signed anything, or you are not certain, the other option, "Send each person the agreement to sign", collects and keeps the signature for you. See How bank debit agreements work in a bulk upload.

What happens if you choose it

Three things change, and all three matter.

1. No resident is asked to sign anything in URBI. No sign request email is created, and none is sent, now or later. The wizard's own wording for this is the first line of the confirmation window: "The residents in this batch will not be asked to sign anything in URBI."
2. URBI holds no resident signature for these bank debits. The second line says it directly: "URBI will hold no resident signature for these bank debits." Every row is marked "Declared by staff" rather than signed. If you later go looking in URBI for a resident's signature on one of these agreements, there will not be one, because none was ever collected here.
3. The debits are treated as authorised from the moment the batch commits. Each row's agreement is created already treated as authorised, and its first debit date is the one you choose, not one that waits for anyone to sign. You choose it, together with a notice date, on the card described in the next section. The commit also bills that first debit straight away: the first charge and its invoice are dated and due on the first debit date, and that day's bank file collects it. No invoice email is sent for this first bill.

There is one row type this path cannot handle. If a payer already holds their own signed agreement in URBI, that agreement is not replaced on this path, and the row says so: "The payer has a signed agreement and it cannot be replaced when staff skip signing."

The responsibility you are taking on

Stated plainly, and it is stated the same way on screen:

"If a resident disputes a debit with their bank, the property is responsible and must produce the signed agreement and written approval."

Read that as it is written. A bank debit can be disputed by the account holder. When that happens on a normal signed agreement, URBI holds the signature and it can be produced. When it happens on a row covered by your declaration, URBI holds no signature, so the evidence has to come from the property's own records. If the property cannot produce the signed agreement and the written approval, it carries the outcome of that dispute.

That is the whole trade in one sentence: you save everyone the work of signing, and in exchange the property, not URBI, is the one holding the proof.

The "Signed paper agreements" card: your two dates

Choosing this option opens a card titled "Signed paper agreements". 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." It has two date fields.

• "Date residents were told (notice date)". The day you told residents about the first debit. The helper reads "Today or earlier."
• "First debit date". The day the first debit is taken. The helper reads "Canadian business days only. The bank file for this date is built on at 7:00 AM Toronto time." The calendar greys out any date that is not a Canadian business day, or whose bank file has already started building.

The rules on the two dates:

• The notice date cannot be after today ("The notice date cannot be after today."), and it must be before the first debit date ("The notice date must be before the first debit date.").
• There must be at least 10 days between the notice date and the first debit date. The card shows how you stand: " days between the notice and the first debit. The notice needs at least 10 days." If the gap is too short you see "Choose a first debit date at least 10 days after the notice date." and "Earliest first debit date for a notice on : ." You cannot get past this yourself. Only URBI can allow a one-time shorter notice, and if that happens everyone sees "URBI allowed a shorter notice."
• The first debit date must be a Canadian business day. If it falls after the 28th, it must be the last day of the month. Its bank file must not have started building. If you pick a date that can no longer be used, you see "That first debit date can no longer be chosen. Its bank file build has started, or it is not a Canadian business day. Pick a later date."

The bank file for a debit date is built at 7:00 AM Toronto time on the debit date itself. You must commit the batch at least 30 minutes before that build. If you commit too late, the commit is refused with "The bank file for starts building at 7:00 AM Toronto time. Pick a later first debit date." or "The bank file build has already started. Pick a later first debit date."

Once both dates are set, you confirm the declaration by typing your full name, as described next.

The confirmation window, line by line

Choosing the option does not save anything. When you press Continue, a window opens, and it blocks the rest of the screen until you deal with it.

The confirmation window, with the five responsibility lines, the declaration statement, and the name field that unlocks Submit.

Working through it in order:

1. The heading reads "You are taking responsibility for these bank debits". This is where your attention lands when the window opens.
2. Five plain lines follow, and they are the five in the picture above. Two describe what will not happen (nobody signs, no signature is held), one states the responsibility, one describes what residents get instead, and one states what is being recorded about you.
3. The declaration statement itself is shown in quotation marks: "I confirm that I hold a signed pre-authorized debit agreement and written approval from every person in this upload, and I accept responsibility for any dispute." This wording never changes. It is not adjusted for your property type or your building's vocabulary.
4. A text field labelled "Type your full name to confirm this declaration", showing "Full name" until you type in it.
5. Two buttons, Cancel and Submit declaration. Submit stays disabled until a name is typed in the field, so the declaration cannot be made with a click alone. While it saves, the button reads "Recording...".

Cancelling is completely safe. It leaves the consent choice exactly as it was, changes nothing and records nothing. This is what makes the path impossible to take by accident: there is no route to it that does not pass through typing your own name and pressing Submit.

If the declaration cannot be saved, you see "Could not record the declaration. Try again." in red, and nothing has been recorded. Try again.

When it works, a short message confirms it: "Declaration recorded for Sarah Chen. Every row in this batch is marked Declared by staff."

What is recorded, and for how long

The window tells you before you submit: "This declaration is recorded with your name, the time, and your device."

Three pieces of information are kept:

• The name you typed, exactly as you typed it. URBI stores what was entered in that field, not your account's display name. A shortened name, a nickname or a typo is stored as it was typed, so type your full name properly.
• The time the declaration was made.
• The device it was made from.

This goes into the property's audit trail, alongside the record of every money change the batch makes. That trail is the permanent record that gets produced when a bank asks who authorised a debit, or when an auditor asks who approved a change. It is not a temporary note and it is not something you can tidy up afterwards. Treat making this declaration as putting your name to it, because that is what it is.

If the batch changes, you declare again

A declaration covers a specific set of bank debit rows, the ones that existed when you made it. If that set changes afterwards, for example you upload more bank details, discard a file, or skip a row, the declaration no longer matches the batch, and you have to confirm it again.

You are told this on the Launch settings step, in a line that stays put until you deal with it:

"This batch changed since you declared it. Confirm the declaration again before you can commit."

Re-open the declaration and submit it again, the same way as the first time.

The system does not take your word for this at commit either: it checks again when the batch commits, and refuses rows rather than letting a stale declaration through. The messages you may see on a bank debit row at commit are:

• "This batch has no completed bypass declaration." The batch is set to the staff declaration path but no declaration was recorded. Make the declaration.
• "The bank debit rows changed after the bypass declaration was made. Attest again before committing." Rows were added or removed after you declared. Declare again.
• "The bypass declaration for this batch could not be matched to its recorded rows. Attest again before committing." The declaration on file cannot be tied to the batch's current rows. Declare again.

This double check is deliberate. It is what stops rows nobody declared from riding along on a declaration made for a different set of people.

If some rows cannot be declared, Launch settings tells you: " of rows cannot be declared and will be skipped for the declaration. The other go ahead."

What residents receive instead

Nobody on this path is asked to sign, but nobody is left in the dark either. Each payer gets one setup email, telling them their bank details are set up and that they do not need to do anything.

• The subject line reads "Your bank payments are set up: ".
• The preview line reads "No action is required."
• It lists the bank, the account ending, the monthly amount, the debit day ("Debited on the 15th of each month" or "last day of each month") and the first debit date. A "View your bank payments" button opens their bank payments.

The confirmation window tells you this will happen before you commit to it: "Every person in this batch will get a notice that their bank details are now on URBI. No action is needed from them."

Unlike the other messages a batch can prepare, this email goes out automatically when the import commits. You do not press Send, and it does not wait on the Send card. It goes as long as at least one row was billed, and each payer gets one email. Residents get no invoice email for the first bill. After the emails have gone, the Send card shows the batch as sent, and a sent batch never sends again.

Which should I choose?

Both options end with the same result in the app: bank debits set up for the people in your batch. They differ in who does the work and who holds the proof.

The same two options, compared on what each one costs and what each one leaves you holding.

In plain terms: asking people to sign costs you time and chasing, and some people will be slow, which pushes their first payment into the following month. Declaring costs you no chasing and starts everyone on time, and in exchange the property carries every dispute on its own paperwork. Neither is the correct answer in general. The honest question to ask before you pick the declaration is whether you could, today, put your hand on a signed agreement and a written approval for every single person in the batch. If the answer is anything other than a confident yes, the other path exists for a reason.

Keeping your paper agreements in URBI

You can attach a scan or photo of each signed paper agreement to its row in the bank agreements list, using the drop area that reads "Drop the signed agreement here". It accepts a PDF, JPG or PNG. It is filed in that unit's PAD Agreements folder and is visible to staff only.

This is optional, and it never blocks a row from committing. It is also worth doing, because this path asks you to be able to produce the signed agreement on request, and a file in the unit's folder is easier to find later than a sheet in a cabinet. Attaching a file does not change the responsibility. The full detail is in How bank debit agreements work in a bulk upload.

Related articles

• How bank debit agreements work in a bulk upload
• Uploading fees, leases and bank debit agreements in bulk: overview
• What you need before you start