Reading the error report, row by row
This article explains every reason a row can fail during a bulk fee and lease upload, and what to do about each one. It is for anyone reviewing the results of an import, whether that import finished...
Last updated
This article explains every reason a row can fail during a bulk fee and lease upload, and what to do about each one. It is for anyone reviewing the results of an import, whether that import finished completely or finished with some rows skipped. Read this alongside the error report you downloaded, or the "Failed to send" list on the Send card, and match the wording you see to the headings below.
What the error report is
When an import finishes, if any rows could not be processed, a Download error report button appears next to Retry failed rows on the results screen. The downloaded file has all the columns from your original spreadsheet, plus one extra column that says exactly what went wrong for that row.
The single most important thing to know: a failed row means that one row did not import. It does not mean the rows around it failed too. Every other row in your file that did not show an error was processed normally. You can fix and retry just the rows that failed, without touching anything else.
A small number of the reasons in this article do not come from the downloaded report at all. They come from the "Failed to send" list on the Send card, which appears after your bank debit and fee messages go out. Those are marked below, because the fix for them is different: instead of retrying a row, you start a new batch.
The finished import screen, with the report and retry buttons a person actually clicks.
Import finished
142 rows processed, 6 need attention.
136
Leases created
6
Rows skipped or failed
Download error report
Retry failed rows
How to work through the report
Working through a batch of failed rows goes faster with a little order. Follow these steps.
- Open the downloaded error report in a spreadsheet program.
- Scan or sort the explanation column so identical reasons sit together. One cause, such as a payer missing an email address, often explains many rows at once, so grouping them saves you from reading the same explanation dozens of times.
- Find the matching heading in this article for each distinct reason and follow its "What to do" steps.
- Fix the cause. For most reasons this means correcting something in your source file (a missing email address, a wrong unit, a missing date) or completing a setup step you had not finished yet (choosing a consent path, submitting a declaration).
- Once the cause is fixed, use Retry failed rows rather than re-uploading the whole file. Retrying only reprocesses the rows that failed. Uploading the whole file again would create a brand new import and risks duplicating the rows that already succeeded.
- Re-upload the whole file only when the report tells you to fix data at the file level and there is no row left worth retrying on its own, for example when a required column was missing entirely, or when you are correcting a value that needs to go through validation again from the start. Where that applies, it is stated in the reason's own instructions below.
- For the reasons that come from the Send card's "Failed to send" list rather than the downloaded report, the fix is different again: you correct the missing piece, then start a new batch to send that person's message. Retrying a row and starting a new batch are not the same action; each heading below tells you which one applies.
A downloaded error report, showing how the same column layout gains one explanation column.
| unit_label | payer_name | error_detail |
|---|---|---|
| Unit 304 | Sarah Chen | The chosen payer has no email address. |
| Unit 512 | Marcus Webb | The row's billing account is frozen. |
| Unit 210 | Aisha Khan | The row could not be claimed. |
Something in your file needs changing
These reasons happen because of something in your uploaded file, a payer you chose, or a setup step you have not finished yet. You (or whoever manages the batch) can fix each one and then retry.
"The chosen payer has no email address."
What it means. The person you selected as the payer for this row has no email address on file, so nothing can be sent to them.
Why it happened. URBI needs an email address to invite a payer who does not have an account yet, and this payer's record has none.
What to do.
- Add an email address for this payer, either in your records or in the payer column of your file.
- Retry failed rows.
"More than one account uses this payer's email address."
What it means. The email address you used for this payer matches more than one existing account, so URBI cannot tell which one you mean.
Why it happened. The email address you gave for the payer is shared by more than one account.
What to do.
- Use a more specific way to identify this payer, such as a different email address, or match them by name and unit first.
- Retry failed rows.
- If you are not sure which account is the right one, contact your URBI administrator with the batch and row number.
"The row does not belong to this batch's property."
What it means. This row is pointed at a different property than the one this batch belongs to.
Why it happened. The unit or record this row refers to sits on another property, not the one you are importing into. This can happen either while payers are being invited or while a held invoice is being raised.
What to do.
- Check the unit assigned to this row in your file and correct it if it belongs to a different property.
- Retry failed rows.
- If the row looks correct as written, contact your URBI administrator with the batch and row number.
"The row does not belong to this batch and property."
What it means. This bank debit row is pointed at a different batch or property than the one being processed.
Why it happened. The bank debit row's unit or batch does not match the property this enrollment is running against.
What to do.
- Check the unit and property assigned to this row.
- Retry failed rows.
- If the row looks correct as written, contact your URBI administrator with the batch and row number.
"This row has no start date."
What it means. This lease row reached the final step with no start date recorded.
Why it happened. The start date is required to create a lease, and none was carried through for this row.
What to do.
- Add a start date to this row in your source file.
- Re-upload the row.
"This row has no validated lease data."
What it means. This row has no usable lease information left to work with.
Why it happened. This can happen for the same underlying reason as "This row has no start date." above; the row reached the final step without a complete, validated set of lease details.
What to do.
- Review this row in your source file and correct any missing or incorrect fields.
- Re-upload the row.
"The held amount is missing or not a positive whole number of cents"
What it means. The fee amount recorded for a held (deferred) fee update is blank, or is not a valid whole-cent amount.
Why it happened. A held fee update needs an amount written as a whole number of cents, and the amount on this row is either missing or not in that form.
What to do.
- If you can see and edit this amount, enter it as a whole number of cents (for example, 45000 for $450.00), then retry.
- If you cannot see where this amount comes from, contact your URBI administrator with the batch and row number.
"Choose how payers give consent before committing."
What it means. Your bank debit batch has bank debit rows, but nobody has chosen how payers will agree to them yet.
Why it happened. A bank debit batch cannot commit until a consent path (payers sign for themselves, or staff declare it on their behalf) has been chosen.
What to do.
- Go to Launch settings for this batch.
- Choose a consent path.
- Commit the batch again.
"This batch has no completed bypass declaration."
What it means. This batch uses the staff declaration path for consent, but the required declaration has not been submitted yet.
Why it happened. The consent path chosen for this batch is the staff declaration, and no declaration has been recorded for it.
What to do.
- Submit the declaration for this batch.
- Retry failed rows.
"The row was not committed, so there is no lease to invoice."
What it means. This row was never committed, so there is no lease for URBI to raise an invoice against.
Why it happened. The invoice-raising step only works on rows that already went through a completed commit. This row did not.
What to do.
- Go back and commit this row.
- Once it is committed, retry raising its invoice.
"The invited payer for this row is not resolved." / "The payer for this row is not resolved."
What it means. Both messages mean the same thing: the person invited to be this row's payer has not been matched to an active account yet, so the step cannot continue.
Why it happened. This usually happens when the invite behind the payer was withdrawn, or the invited person is no longer active at this property.
What to do.
- Re-invite the payer.
- Re-upload the row.
"The person has no account or live invite email."
What it means. This person has neither an existing account nor a still-valid invite email, so no message could be prepared for them.
Why it happened. URBI could not find a working way to reach this person. This reason appears in the Send card's "Failed to send" list, not the downloaded error report.
What to do.
- Add an email address for this person.
- Start a new batch to send their message; this batch's send cannot be retried for this one person.
"The message names no billing account."
What it means. The prepared message for this person has no billing account attached to it, so URBI does not know which account it concerns.
Why it happened. The billing account this message needs is missing. This reason appears in the Send card's "Failed to send" list.
What to do.
- Confirm the billing account for this row exists and is on this property.
- Start a new batch to send this person's message.
"The agreement has no bank details to show."
What it means. The bank debit agreement behind this message has no bank details recorded, so there is nothing to show the payer.
Why it happened. The bank details expected on this agreement are missing. This reason appears in the Send card's "Failed to send" list.
What to do.
- Confirm the bank details were captured for this agreement.
- Start a new batch to send this person's message.
"The message names no agreement."
What it means. This message was supposed to be about a bank debit agreement, but no agreement is attached to it yet.
Why it happened. The bank debit row behind this message has not been committed, so its agreement does not exist yet. This reason appears in the Send card's "Failed to send" list.
What to do.
- Commit the bank debit row first.
- Start a new batch to send this person's message.
"Batch does not belong to the supplied property"
What it means. The import batch this run tried to work on does not belong to the property it was told to run against.
Why it happened. This is a whole-batch check made before any row is processed. The batch record on file belongs to a different property than the one the run started from.
What to do.
- Close this batch and reopen it from the correct property in Bulk Actions.
- Try again.
- If you believe you are already in the right property, contact your URBI administrator with the batch number.
"An active lease already exists and was not approved for update."
What it means. This row was skipped on purpose. The unit already has an active lease, and during Review you were not asked to update it, or you chose not to. This is a normal outcome, not a fault.
Why it happened. At Review, staff either chose "Refuse" for this collision, or made no explicit choice, so URBI left the existing lease untouched rather than overwrite it.
What to do. If leaving the existing lease alone was what you intended, nothing further is needed. If you meant to update it instead, re-upload this row and choose Update when the collision is shown again. See Errors about units and leases for the collision screen itself.
"The bypass declaration has no valid date"
What it means. The date recorded when the staff declaration was submitted could not be read as a valid date.
Why it happened. The timestamp stored against the declaration is missing or unreadable.
What to do.
- Submit the declaration again.
- Retry failed rows.
The unit or its account was not in a usable state
These reasons mean the billing account or lease behind the row was not in a state that could be used at that step. There is usually nothing you can tell from your spreadsheet alone; someone with access to the unit's billing account needs to look at it.
"The row carries no billing account."
What it means. This row has no billing account attached to it, so the payer invite could not be created.
Why it happened. The source does not say why the billing account is missing for this row.
What to do. Contact your URBI administrator with the batch and row number.
"The row's billing account is frozen."
What it means. The billing account this row would bill against is frozen.
Why it happened. The unit's billing account has been placed on hold, which blocks new activity against it, including a payer invite.
What to do. Ask your URBI administrator to check why the account is frozen. Once it is resolved, retry failed rows.
"The lease has no billing account."
What it means. The lease behind this row exists, but it has no billing account attached to it.
Why it happened. The source does not say why the billing account is missing for this lease.
What to do. Contact your URBI administrator with the batch and row number.
"The active lease has no billing account"
What it means. The unit's existing active lease has no billing account attached to it, so its fee could not be updated or resumed.
Why it happened. This is checked while re-applying an approved fee update, or resuming a fee activation, against a unit's existing lease. On screen this can appear with a prefix in front of it, such as "Could not resume condo fee activation:" or "Could not apply the approved fee update:".
What to do. Contact your URBI administrator with the batch and row number so the unit's billing account can be corrected.
"The active lease already has a condo fee schedule"
What it means. While picking up a fee activation already in progress for this unit, URBI found the unit's active lease already carries a different, unrelated recurring fee schedule.
Why it happened. Another charge schedule exists on this lease that this row's own activation does not own. On screen this can appear with the prefix "Could not resume condo fee activation:" in front of it.
What to do. Contact your URBI administrator with the batch and row number so they can check which schedule is correct for this unit before this row is retried.
"The active lease has more than one condo fee schedule"
What it means. The unit's existing active lease has more than one recurring condo fee schedule attached to it, so URBI cannot tell which one to update.
Why it happened. This is checked while applying an approved amount update to an existing lease. On screen this can appear with the prefix "Could not apply the approved fee update:" in front of it.
What to do. Contact your URBI administrator with the batch and row number so the extra schedule can be resolved before this row is retried.
Something was missing that should have been recorded
These reasons come from the step that raises an invoice for a fee that was deliberately held back earlier (for example, because the payer did not exist yet at commit time). By the time this step runs, it expects certain details to already be sitting on the lease or the batch from that earlier commit. When one of those details is not there, the invoice cannot be raised. None of these can be fixed by editing your spreadsheet; the earlier commit has already happened.
"Neither the batch nor the lease records a fee start date."
What it means. URBI looked in two places for this fee's start date, the batch and the lease, and found it in neither.
Why it happened. The fee start date was not carried through from the original commit.
What to do. Contact your URBI administrator with the batch and row number.
"The fee amount or billing day recorded at commit is missing."
What it means. The fee amount or the billing day that should have been recorded when this row was committed is missing.
Why it happened. One of the two values the invoice needs was not carried through from the original commit.
What to do. Contact your URBI administrator with the batch and row number.
"The fee period the invoice was held for is not recorded."
What it means. URBI held this invoice back to raise later, but the record of which billing period it was being held for is missing.
Why it happened. The held period was not carried through from the original commit.
What to do. Contact your URBI administrator with the batch and row number.
"The charge schedule created at commit no longer exists for this lease." / "The row has no charge schedule recorded from commit."
What it means. Both messages mean the recurring charge schedule this invoice needs is not there for this lease, either because it no longer exists or because it was never recorded against this row.
Why it happened. The charge schedule that was created (or should have been created) when the row was committed cannot be found now.
What to do. Contact your URBI administrator with the batch and row number.
"The row has no lease recorded from commit."
What it means. This row was committed, but no lease is recorded against it now.
Why it happened. The lease that should have been recorded from the original commit is missing.
What to do. Contact your URBI administrator with the batch and row number.
Two things happened at once
These reasons come from timing. Another automatic run of the same job touched this row, or something changed, or turned out to already be true, at the same moment this step ran. Nothing is usually broken, and no lasting action is normally needed. Retrying is the normal answer where a retry makes sense.
"The row could not be claimed."
What it means. URBI could not lock this row for exclusive processing at that moment.
Why it happened. This happens under genuine timing pressure, when the row was briefly being touched by more than one process. It can occur either while payers are being invited or while a held invoice is being raised.
What to do. Retry failed rows. This usually succeeds on the next attempt once the timing clash has passed.
"The row's claim changed before the payer could be recorded." / "The row's claim changed before the invoice could be recorded."
What it means. Both messages describe the same kind of clash: URBI had claimed this row to work on it, but the claim changed underneath it before the payer, or the invoice, could be written.
Why it happened. Another process affected the same row's claim while this step was still running.
What to do. Retry failed rows.
"Another release is raising this invoice right now." / "Another release resumed this invoice first."
What it means. Both messages mean another automatic run of the invoice-raising job got to this row either at the same time, or just before this one did.
Why it happened. This is a timing collision between two runs of the same automatic job.
What to do. You usually do not need to do anything; check shortly afterward whether the invoice was raised by the other run. If it still shows as failed, retry failed rows.
"The import batch was not found."
What it means. By the time this step ran, the import batch it needed no longer existed.
Why it happened. The batch was removed before this task ran.
What to do. Nothing needs fixing; the work for this row was simply abandoned along with the batch, not lost silently. If you expected this batch to still exist, contact your URBI administrator.
"The bank debit row was not found."
What it means. By the time this step ran, the specific bank debit row it needed no longer existed.
Why it happened. The source does not say more than this; it usually means the row was removed or replaced before this step could run.
What to do. No action is normally needed. If you expected this row to be processed, contact your URBI administrator with the batch and row number.
"Every agreement on this message is already signed."
What it means. Every bank debit agreement this message was about has already been signed.
Why it happened. The agreement was signed before the message could be sent about it.
What to do. Nothing. No message is needed once the agreement is already signed.
"Every update for this person kept the same amount."
What it means. Every amount change recorded for this person, for this send, worked out to the same amount they already had.
Why it happened. There was no real change to tell this person about.
What to do. Nothing; no notice is needed.
"A bank debit agreement appeared after this row was reviewed. Refresh Review before committing so the replacement is shown to staff."
What it means. Another bank debit agreement for the same payer, on the staff declaration path, was created after this row was last reviewed, and staff has not yet seen it.
Why it happened. The batch's Review step was not refreshed after the new agreement appeared, so this row would otherwise commit without staff seeing the replacement.
What to do.
- Go back to Review and refresh it.
- The new agreement will then be shown to staff before you commit.
Something went wrong reading or writing
These reasons come from a step that could not read or write something it needed. They are the most likely to need someone to actually look, rather than a simple retry.
"Could not audit the created lease" / "Could not audit the created billing account"
What it means. Both messages mean the same kind of thing happened, on a different record. The lease, or the billing account, was actually created. What failed afterward was writing the audit trail entry that is supposed to record who created it and when.
Why it happened. The write that creates the record succeeded, but the follow-up write that logs it to the audit trail failed.
What to do. This is more serious than most reasons in this article: the record exists, but it has no audit entry behind it. An accounting record without its audit trail matters to your auditors and to your bank. Contact your URBI administrator with the batch and row number so they can confirm the record and add the missing audit entry.
"Failed to read the bank debit row claim" / "Failed to read the earlier bank debit agreement" / "Failed to read the reusable agreement bank account" / "Failed to read the reusable agreement source row"
What it means. All four messages mean a step enrolling a bank debit row could not read something it needed partway through: this row's own hold on itself, an earlier agreement it was replacing, or the bank account and source row behind an agreement being reused across rows for the same payer.
Why it happened. The source does not say more than that the read failed.
What to do. You cannot fix this from your file. Contact your URBI administrator with the batch and row number.
"The staged bank details had an unexpected shape"
What it means. The bank details staged for this row came back from storage in a form URBI did not recognise.
Why it happened. The source does not say more than this.
What to do. Contact your URBI administrator with the batch and row number.
"The reusable bank debit agreement has no source row"
What it means. URBI tried to reuse an existing bank debit agreement for this payer, but could not tell which earlier row originally created that agreement.
Why it happened. The agreement being reused is missing the record of the row that created it.
What to do. Contact your URBI administrator with the batch and row number.
"The conflicting bank debit rows have no source row numbers"
What it means. Two rows in this batch disagree about the bank account for the same payer, and URBI could not identify either row by its own row number to tell you which two.
Why it happened. The source does not say more than this.
What to do. Contact your URBI administrator with the batch and row number.
"The active lease could not be read"
What it means. URBI had already found the unit's active lease, but a follow-up read of that same lease came back empty.
Why it happened. The source does not say more than this. On screen this can appear with the prefix "Could not apply the approved fee update:" in front of it.
What to do. Contact your URBI administrator with the batch and row number.
"Bank debit readiness could not be checked, so no bank debit agreement was created. Retry the import to try them again."
What it means. URBI could not confirm whether this property is still set up to collect by bank debit, so none of this batch's bank debit rows were enrolled.
Why it happened. The check itself failed to run.
What to do. Retry the import.
"The bank debit rows could not be processed. Retry the import to try them again."
What it means. The whole step that enrolls this batch's bank debit rows failed to run.
Why it happened. The source does not say more than this.
What to do. Retry the import.
"The bank debit rows could not be read, so no bank debit agreement was created. Retry the import to try them again."
What it means. URBI could not read this batch's bank debit rows at all, so none of them were enrolled.
Why it happened. The source does not say more than this.
What to do. Retry the import.
"The bank debit agreement for this row could not be created. Retry the import to try this row again."
What it means. This one row's bank debit agreement could not be created.
Why it happened. This message replaces a more specific internal reason when the enrollment step for this one row fails; the row itself was not enrolled.
What to do. Retry the import. If it keeps failing, contact your URBI administrator with the batch and row number.
"The created condo lease has no billing account." / "The lease could not be created."
What it means. Both messages come from the step that creates leases while committing your file. The first means a lease was created but ended up with no billing account; the second means the lease itself could not be created at all.
Why it happened. A read or write the commit step needed failed partway through processing this row.
What to do. Retry failed rows. If it keeps failing, contact your URBI administrator with the batch and row number.
"The invoice step returned nothing."
What it means. The step that raises this row's invoice ran, but did not come back with a result.
Why it happened. The source does not say more than this.
What to do. Retry failed rows. If it keeps failing, contact your URBI administrator with the batch and row number.
"The property could not be read."
What it means. The step preparing this message could not read the property record it needed.
Why it happened. The source does not say more than this. This reason appears in the Send card's "Failed to send" list.
What to do. Contact your URBI administrator with the batch and row number. Once they confirm it is fixed, start a new batch to send this person's message.
"No update row names this person."
What it means. URBI could not find the record it needed to describe an amount change to this person.
Why it happened. The commit did not record the amount this person's fee changed from, so the change cannot be described to them.
What to do. Contact the person directly to explain the change; URBI cannot include the amount in an automatic message for this row.
What to do if the same reason appears on many rows
If you scan the explanation column and see the same wording on ten rows, or fifty, that almost always means one setting or one column in your file is wrong, not that fifty separate things went wrong. Fix the one underlying cause (a missing column, a property mismatch, an unfinished setup step), then retry the failed rows together. You should very rarely need to investigate each row individually when the reason repeats.
Related articles
- Overview
- Uploading your file, step by step
- After you commit
- Errors about payers and emails
- Errors about bank debit
- Errors about fees and dates
- Errors when someone else changed it
- Errors when sending messages