Bank debit rows that are refused or need confirming
This article explains every message that lands on a single bank debit row: the conflicts that stop a row from getting an agreement, the tick boxes that let you go ahead anyway, the refusals that...
Last updated
This article explains every message that lands on a single bank debit row: the conflicts that stop a row from getting an agreement, the tick boxes that let you go ahead anyway, the refusals that appear only when you commit, and the messages you can meet while attaching a signed paper agreement. It is written for property managers, building staff and board members.
Two things to know before you start reading.
- Names, unit numbers, dates and row numbers inside the quoted messages are examples. Your screen shows the real ones for your property.
- A refused or unconfirmed bank debit row never stops a fee or lease row from importing. Each entry below says so where it applies, and where a problem has exactly one remedy and no override, it says that plainly too.
If your message is not in this article, the full "Find your problem fast" table at the top of Bank debit problems and what they mean routes every message in the set to the article that explains it.
A row says it cannot have a bank debit agreement
The bank debit review table shows one row per person, with an Agreement column. When a row cannot have an agreement, that column reads "Refused", and a panel on the row explains why. Some of these have a tick box you can use to go ahead anyway. Others have exactly one remedy and no override, and those are marked clearly below.
In every case in this section, the fee row for that unit still commits. A refused bank debit row never stops a fee or a lease from importing.
A review row where the payer already has an agreement somewhere else, with the tick box that lets you go ahead.
| Sarah Chen · Unit 304 | ending in 6789 | Needs confirming |
Sarah Chen already holds a live bank debit agreement on a different billing account. Confirm this row to add a second agreement here.
✓ |
Add this bank debit agreement here; Sarah Chen's agreement on the other account is unchanged |
"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."
What it means. The account that this unit's charges are billed to is already set up to pay by bank debit. URBI will not put a second agreement on the same account, and there is no tick box, no override and no way to force it from this screen.
Why it happened. A live bank debit agreement capable of taking debits already sat on that billing account when your file was uploaded.
What to do.
- Decide whether the agreement already in place is the correct one. Often it is, and you need do nothing at all.
- If you want your uploaded details used instead, cancel the existing agreement outside this importer, from the payer's own payment settings.
- Upload this row's bank details again afterwards.
- Either way, commit the batch. The fee row for that unit imports as normal.
"Sarah Chen already pays this billing account by bank debit, since 3 March 2026. There is no override for this row; it is excluded from bank debit setup. Cancel that agreement from Sarah Chen's payment settings first, then upload this row again. The fee row for Unit 304 still commits."
What it means. A different person from the one on your row is already paying this unit's account by bank debit, and has been since the date shown. Two people cannot both hold a live agreement on the same account. There is no override for this row.
Why it happened. Someone else's live agreement already covers that billing account.
What to do.
- Check with the property whether the person named in the message should still be the payer. If they should, leave everything alone; nothing is broken.
- If the payer is genuinely changing, cancel the named person's agreement from their own payment settings.
- Upload this row's bank details again once that is done.
- The fee row for that unit commits in this batch regardless of which way you go.
"Sarah Chen already holds a live bank debit agreement on a different billing account. Confirm this row to add a second agreement here."
What it means. This person already pays something else by bank debit, on a different account, for example another unit they own. Adding this row gives them a second agreement. URBI will not decide that for you, so it asks you to confirm.
Why it happened. The payer holds a live agreement elsewhere.
What to do.
- Check that a second agreement is really what you want. It means this person will be debited for both accounts.
- Tick the box that reads "Add this bank debit agreement here; Sarah Chen's agreement on the other account is unchanged". Their existing agreement is not touched.
- If you leave the box unticked, this bank debit row is refused when you commit. The fee row still commits.
"Sarah Chen set up their own bank payments after this file was uploaded. Confirming adds this row's bank debit agreement alongside theirs; their own agreement is unchanged."
What it means. Between the moment you uploaded the file and now, this person went and set themselves up to pay by bank debit. Your row would add a second agreement on top of theirs.
Why it happened. An agreement appeared on that billing account after your file was uploaded, created by the resident rather than by you.
What to do.
- Consider leaving the row unticked. The person has already done the work themselves, and their own agreement continues.
- If you still want your row added as well, tick "Add this bank debit agreement here; Sarah Chen's own agreement is unchanged".
- An unticked row is refused at commit, and the fee row still commits.
"This row could not be confirmed."
What it means. You ticked the confirm box and the tick was not saved, so the row is still unconfirmed and will be refused at commit.
Why it happened. The save of your confirmation failed.
What to do. Tick the box again. If it will not stick, reload the import and tick it once more. A second wording for the same failure is "PAD conflict could not be confirmed"; if that one repeats, contact your URBI administrator.
"The payer has a signed agreement and it cannot be replaced when staff skip signing."
What it means. This person personally signed a bank debit agreement. You have chosen the path where staff declare they already hold signed agreements rather than asking people to sign. URBI will not overwrite a document the person signed using a declaration. Nothing can be done about this row from this screen.
Why it happened. The payer holds a signed agreement, and this row clashes with it while the staff declaration path is in use.
What to do. Leave the row. It is excluded from bank debit setup and the fee row still commits. If the person's bank account genuinely needs to change, that change belongs in their own payment settings, not in a bulk upload.
"The payer's signed agreement covers all of their units. These uploaded bank details cannot replace it. Skip this bank debit row so the fee row can still commit."
What it means. This person signed one agreement that already covers every unit they hold, including this one. Your uploaded details cannot replace it. There is one button, and it removes the bank debit row so the rest of the batch can proceed.
Why it happened. The payer holds a signed agreement that already covers this billing account.
What to do.
- Press Skip bank debit for this row. The button reads "Skipping..." while it works.
- The bank debit row leaves the batch. The fee row for that unit still commits.
- If you change your mind, upload the bank details file again to bring the row back.
"The payer already has a signed agreement. A new agreement will be sent for signature, and the existing debit will continue until the new agreement is signed."
What it means. This is a notice, not a refusal. The person has an agreement already, a fresh one will go out for them to sign, and in the meantime their current debits carry on so no payment is missed.
Why it happened. The payer holds a signed agreement and the row does not clash with either of the two situations above.
What to do. Nothing. Carry on with the batch. Expect the person to receive a sign request.
"Sarah Chen in Unit 304 was skipped for bank debit. To restore it, upload the bank details file again."
What it means. Your skip worked. That person's bank debit row has been removed from this batch. Their fee row is untouched and still commits.
Why it happened. You pressed Skip bank debit for this row.
What to do. Nothing, unless you want the row back. To bring it back, upload the bank details file again.
Problems attaching a signed paper agreement
On each bank debit row in Review there is an optional area reading "Drop the signed agreement here" (on a phone, "Tap to add the signed agreement"). Attaching a paper agreement is optional on both consent paths and never blocks anything. These are the messages it can show.
"A file up to 25 MB is required"
What it means. The file you dropped is larger than 25 MB, or no file arrived.
Why it happened. Scanned agreements are often saved at a very high resolution.
What to do. Re-scan or re-save the document at a smaller size, in PDF, JPG or PNG, and drop it again.
"A file name is required"
What it means. The file arrived without a usable name, so it cannot be filed.
Why it happened. The file has no name URBI can work with.
What to do. Rename the file on your computer, for example to "Unit 304 signed agreement.pdf", and drop it again.
"Resolve the unit before attaching paperwork"
What it means. Paperwork is filed into a specific unit's folder, and this row is not yet tied to a unit, so there is nowhere to put it.
Why it happened. The bank debit row has no resolved unit.
What to do.
- Fix the unit on that row first. See the "Needs review" entry in Bank debit problems and what they mean.
- Once the row shows a unit, attach the paperwork again.
"PAD row not found"
What it means. The row you are attaching to could not be found, so nothing was filed.
Why it happened. The row id is unknown, or the read failed. A second wording for the same problem is "Failed to fetch PAD row".
What to do. Reload the import, find the row again, and attach the file once more.
"Failed to prepare the unit documents folder"
What it means. The document storage step failed, so the paperwork was not filed. Nothing else about the row changed.
Why it happened. A storage step did not complete. You may see any of these related wordings: "Failed to find PAD folder", "Failed to create PAD folder", "Failed to upload paperwork", "Failed to file paperwork", or "Document storage is not configured".
What to do. Try attaching the file again. If you see "Document storage is not configured", there is nothing you can fix on this screen; contact your URBI administrator.
"Upload failed"
What it means. The attachment did not go through. The server's own reason is shown next to this text, and a Retry button sits in the drop area.
Why it happened. The attachment request failed.
What to do. Press Retry. A related fallback wording, "The paperwork could not be uploaded", means the upload failed with no reason given; press Retry for that too. Remember that paperwork is optional and never blocks the commit.
Problems that only appear when you commit
Some checks can only run at the moment of commit, because they look at live agreement data. When one of these refuses a bank debit row, the reason is stored on the row and shown again on the result screen. A refused bank debit row never stops the fee and lease rows from importing.
"This billing account already had a live bank debit agreement when the file was uploaded, so this row cannot add another."
What it means. The account this unit is billed to was already paying by bank debit. This row was excluded. There is no override.
Why it happened. A live agreement sat on the billing account when the file was uploaded.
What to do. Cancel the existing agreement from the payer's own payment settings if you genuinely want to replace it, then upload this row's bank details again in a new batch.
"This payer already has a live bank debit agreement on another billing account. Confirm the row before committing."
What it means. The row needed you to tick its confirm box in Review, and the box was never ticked, so the row was refused.
Why it happened. The confirmation tick box on that row was left unticked.
What to do.
- Go back to the Review step.
- Find the row and tick "Add this bank debit agreement here; the agreement on the other account is unchanged".
- Retry the bank debit row.
"A bank debit agreement was set up on this billing account after the file was uploaded. Confirm the row before committing."
What it means. The same situation as above, for an agreement that appeared after your file was uploaded, usually because the resident set themselves up.
Why it happened. The row's confirm box was not ticked.
What to do. Decide whether you still want a second agreement. If you do, tick the box in Review and retry. If you do not, leave it; the resident's own agreement continues and the fee row has already committed.
"This billing account already has a live bank debit agreement for Sarah Chen set up on 3 March 2026. Cancel that agreement first, then upload this row again."
What it means. A different person holds the live agreement on this unit's account. Only one person can. There is no override.
Why it happened. A live enrolment for another payer covers that billing account.
What to do. Cancel the named person's agreement from their own payment settings, then upload this row's bank details again.
"One payer has one agreement, but rows 4 and 9 disagree about the bank account. Make both rows use the same account before committing."
What it means. Two committed rows for the same person name different bank accounts, and one person can only have one.
Why it happened. The rows named in the message carry different institution, transit or account numbers for the same payer.
What to do. Correct the file so every row for that person uses one bank account, then upload those rows again.
"The bank details for this row are no longer available. Upload this row's bank details again."
What it means. The bank details behind the row were gone by the time the commit ran, so no agreement could be created.
Why it happened. The staged bank details were consumed or cleared away. Uploaded bank details are also removed after 30 days.
What to do. Upload that row's bank details again. See A row needs its bank details uploaded again.
"This property has no current bank debit agreement wording, so no agreement can be created."
What it means. There is no published agreement wording for the property, so there is no document to create for anyone.
Why it happened. The property's agreement wording was not published, or was withdrawn before the commit ran.
What to do. Publish the bank debit agreement wording for the property, then retry the bank debit rows.
"This property does not have exactly one active bank debit collection set up."
What it means. The property must have exactly one active collection set-up for bank debits. It currently has none, or more than one, so URBI does not know where to send the money.
Why it happened. Zero, or several, active collection set-ups exist.
What to do. Fix the collection set-up in Bank and payments so exactly one is active, then retry.
"Bank debit agreements are available only for Canadian properties."
What it means. The property is not Canadian, so no bank debit agreement can be created for it.
Why it happened. The property's country is not Canada.
What to do. If the country is recorded incorrectly, correct it on the property and retry. If the property really is outside Canada, bank debit is not available; your fee and lease rows still commit.
"You do not have permission to manage payments at this property."
What it means. The bank debit rows were left out because the person committing does not hold the payments permission. The rest of the upload was still processed, and the commit screen names how many bank debit rows were left out.
Why it happened. The committing staff member lacks the payments permission at this property.
What to do.
- Ask a property administrator for the payments permission.
- Or ask a colleague who holds it to handle the bank debit rows.
- Either way, your fee and lease rows have already imported.
"Failed to read the current bank debit agreements"
What it means. The commit could not read the live agreements, so it stopped rather than risk creating a duplicate agreement.
Why it happened. The read of existing signed agreements failed.
What to do. Retry the commit. If it fails again, contact your URBI administrator.
"Refused" and "Not processed"
What it means. When you commit a batch where you declared that you already hold signed paper agreements, the result screen lists every row that did not get a bank debit agreement in one of two groups. Refused rows broke a rule. Each one shows its reason and what to do next, and there is a Download error report button. Refused rows are not retried. Not processed rows were not handled this time, and you can try them again with the Retry button, which shows how many rows it covers, for example "Retry 3 rows".
Why it happened. A refused row failed a rule that checks the live agreement data at the moment of commit. The entries below explain the refusals you can see. A row that was not processed did not get a final answer this time.
What to do. For Refused rows, read the reason, fix its cause if you can, and bring the row in again in a new batch. For Not processed rows, press the Retry button. Your fee and lease rows are not held up by either group.
"A newer bank debit agreement replaced this one. Nothing was billed."
What it means. Another, newer bank debit agreement for this payer took the place of the one this row would have recorded. The row was refused, and no first bill was created for it.
Why it happened. The payer's agreement changed between the declaration and the commit.
What to do. Look at the payer's current agreement in their payment settings. If the newer agreement is the right one, leave the row refused.
"The payer cancelled this bank debit agreement. Nothing was billed."
What it means. The payer cancelled their bank debit agreement, so this row was refused and no first bill was created.
Why it happened. The agreement was cancelled before the commit ran.
What to do. Do not retry the row. If the payer wants to pay by bank debit again, they need a new agreement.
"The payer set up their own bank debit in the app. Nothing was billed under the paper agreement."
What it means. This person set up their own bank debit in the app, so their own agreement is the one in place. Your row was refused and no first bill was created under the paper agreement.
Why it happened. The payer set themselves up before the commit ran.
What to do. Leave the row. The payer's own agreement continues.
"This payer already pays by card or another autopay on this account."
What it means. The billing account is already paid by card or by another automatic payment, so URBI did not add a bank debit on top of it.
Why it happened. An automatic payment method is already in place on that account.
What to do. If you want this payer on bank debit instead, change how the account pays from the payer's own payment settings, then bring the row in again in a new batch. Otherwise leave it.
"Fee is not monthly"
What it means. A signed paper agreement records a monthly bank debit equal to the fee. The fee on this row is not billed monthly, so the row was refused.
Why it happened. The fee's schedule is something other than monthly.
What to do. If the fee should be monthly, correct it and bring the row in again in a new batch. Otherwise leave the row refused.
"Lease splits are active"
What it means. This row was refused because splits are active on the lease, and a signed paper agreement cannot be recorded for it.
Why it happened. The lease has splits turned on.
What to do. The result screen shows what to do next beside the row. Refused rows are not retried.
"The bank file for 16 November 2026 starts building at 7:00 AM Toronto time. Pick a later first debit date."
What it means. The commit has to happen at least 30 minutes before the bank file for the first debit date is built. The bank file for each debit date is built at 7:00 AM Toronto time on that date. You are too close to the date you chose, so the commit was refused.
Why it happened. The first debit date you picked in the declaration is too close, and the 30 minute margin before its 7:00 AM build is gone.
What to do. Go back to Launch settings, choose a later first debit date, confirm the declaration again if you are asked to, and commit again.
"The bank file build has already started. Pick a later first debit date."
What it means. The 7:00 AM build of the bank file for your first debit date has already begun, so that date can no longer be used.
Why it happened. The commit ran after the build started.
What to do. The same as above: choose a later first debit date on Launch settings and commit again. See Problems with the notice date and the first debit date for the rules on that date.
"Exactly one active bank debit rail is required"
What it means. This appears later, when the property's debit file is produced, not during the import. It means the collection set-up is not in the one active state the file needs.
Why it happened. Zero, or more than one, active collection set-up exists at that moment.
What to do. Fix the collection set-up in Bank and payments so exactly one is active, then produce the debit file again. A related wording, "Failed to verify the bank debit rail", means the check itself failed; try again.