Problems with payers and email addresses
This article explains every message you can see on the Payer step of the bulk fees and leases upload, and the related messages that show up later, at commit or when sending, because of who a payer is...
Last updated
This article explains every message you can see on the Payer step of the bulk fees and leases upload, and the related messages that show up later, at commit or when sending, because of who a payer is or whether they have an email address on file. It is for property managers, building staff and board members running the upload. For the step itself, see Matching units and payers.
Choosing a payer for every unit
The Payer step asks you to choose who pays for each unit before its fee and lease can be created. It lists only the rows that need a person. Rows that matched on their own sit under "Matched (N)", with a "Hide matched" control, each tagged "No action needed". A banner at the top of the step tells you how much is left to do.
" matched automatically, needs you."
What it means. The step found a payer for n rows by itself and needs a decision from you on m rows.
Why it happened. An exact email match resolves itself when it points to the one person on the unit.
Leaving payer_name blank in your file also resolves itself: the row uses the unit's current payer, which
is the one person holding the unit's billing account. If the unit has no such person, or more than one,
the row needs a choice and reads "Choose a payer. This
What to do. Work through the rows that are listed. You do not need to touch the matched rows.
"${n} matched automatically, ${m} needs you." / "Every payer is resolved."
What it means. The first message counts the rows that matched on their own and the rows that still need a payer decision. The second appears once every row either has a payer choice or was already skipped earlier in the upload.
Why it happened. The step checks every non-skipped row each time it loads. A row that matched on its own counts as decided. Any other row needs a saved payer choice.
What to do. Work through the rows named in the count, using Invite, Choose someone on this unit, or Switch person on each one, until the message changes to "Every payer is resolved."
"Continue enables once every resident decision is made"
What it means. This is the caption under the greyed-out Continue button.
Why it happened. At least one row that is not skipped still has no payer choice saved.
What to do. Make the remaining choices. The button lights up on its own once every row is covered.
Understanding the match next to each row
Each row shows the unit and payer name from your file, the email address (or a note that there is none), and a coloured tag showing how confident the system is in its automatic match.
"Email match", "Name match", "Close name match, check it", "No match"
What it means. These four tags describe how the row's payer name was matched against the people already recorded on that unit. A row with no payer name in the file can instead show the "Current payer" tag, which means it uses the unit's current payer. "Email match" means the file's email matched an existing person exactly. "Name match" means the name matched closely enough on its own. "Close name match, check it" means the match is uncertain. "No match" means nobody on the unit resembled the name in your file at all.
Why it happened. The upload runs an automatic matching check against everyone already on each unit, using whatever combination of name and email your file provides.
What to do. For "Email match" and "Name match", you do not need to do anything unless you can see the match is wrong. For "Close name match, check it" and "No match", look closely, and correct the row using Switch person or the choice cards described below.
"Switch person"
What it means. This single button appears whenever a match, of any confidence, was found. It opens the same picker used to choose a payer from scratch.
Why it happened. A match exists, but you may still need to override it if it names the wrong person.
What to do. Use it only when the automatic match is wrong. If it is correct, leave the row alone.
| Unit 412 · Marcus Webb | No match |
No email in file
Invite Marcus Webb Suggested. Adds a new invited person to Unit 412 and makes them this row's payer. |
Choose someone on this unit Opens the same picker used to switch a payer: registered and pending people on Unit 412. |
A payer row with no automatic match, showing its "No match" tag and its two choice cards.
Inviting a new person as the payer
"Invite ${payerName}"
What it means. This card offers to create a new invited person on the unit and make them this row's payer.
Why it happened. Nobody on the unit resembled the payer name in your file, so there is no existing person to pick.
What to do. Choose this card if the payer genuinely is a new person for this unit. It opens a small panel where you confirm or type their email address, then Save this choice.
"Nobody is created or emailed until you send the messages."
What it means. Saving an invite choice here does not, by itself, create the person or send anything. That is the rule for a batch where each person is sent the agreement to sign.
Why it happened. This line always shows inside the invite panel.
What to do. Nothing yet. In a send-to-sign batch, the invitation is created only when you release the messages later, from the Send card. If you declared signed paper agreements for the batch, the payer is billed at commit even if they have no URBI account yet, and their setup email goes out automatically at commit. You do not release it from the Send card.
Picking an existing person as the payer
"Choose someone on this unit"
What it means. This card opens a picker listing everyone already on the unit, registered or invited, so you can pick one of them as the payer instead of inviting someone new.
Why it happened. Shown for the same reason as the Invite card: no automatic match was found. It is also reachable through Switch person when a match exists but is wrong.
What to do. Choose this card, pick the right person from the list titled "People on Unit ${unit}", and select Save this choice.
"Invited, not yet registered"
What it means. This label appears under a person in the picker whose account has not been created yet. They exist only as an invitation so far.
Why it happened. The person is recorded as an invited person, not a signed-up user.
What to do. It is fine to pick them. Nothing extra is needed on this screen.
Who cannot be picked as a payer, and why
Some people in the picker are shown greyed out and cannot be selected. The line underneath their name always states the real reason:
"${OccupantTypeLabel}s cannot be payers." (for example, "Dependents cannot be payers.")
What it means. This person's role on the unit does not allow them to be a payer.
Why it happened. The person is recorded as a dependent occupant type, which is never eligible to hold a fee or lease as payer.
What to do. Pick a different person, or use Invite to add someone new.
"This person no longer lives at this unit."
What it means. This person used to be on the unit, but their record shows they have moved out or been removed.
Why it happened. Their record on the unit carries an end date in the past.
What to do. Pick a different, current person on the unit, or invite someone new.
"This invited person is archived."
What it means. An invitation exists for this person, but it has been closed and can no longer be used.
Why it happened. The invitation record has been archived, usually because it was withdrawn or replaced.
What to do. Pick a different person, or send a fresh invitation using the Invite card instead.
After you save a choice
"Payer choice recorded"
What it means. The row's controls are replaced by this line once your choice has been saved.
Why it happened. The payer resolution for this row saved successfully.
What to do. Nothing. Move on to the next row.
"Skipped"
What it means. This row needs no payer choice at all.
Why it happened. The row was already marked to skip during an earlier step of the upload.
What to do. Nothing. Skipped rows are not part of the import.
When the step itself fails to save or load
"Could not save the choice"
What it means. Your payer choice for a row did not save.
Why it happened. The save request to record the payer resolution failed.
What to do. Press Save this choice again. If it keeps failing, contact your URBI administrator.
"Could not load people"
What it means. The step could not load the list of people you can pick from for a unit.
Why it happened. The read that fetches registered and invited people for the unit failed.
What to do. Reload the import and try again.
When a payer has no email address
This is one of the most important situations in this article, because it has real consequences for bank debit agreements. Read this section fully if any of your payers have no email address in your file.
"No email in file"
What it means. This note appears under a payer's name when your uploaded file left the email column blank for that row.
Why it happened. The row has no recorded email address.
What to do. This is optional for the fee and lease itself; you can still pick an existing person, or type an email address by hand when inviting a new one. It only becomes a problem for a bank debit row, described below.
"Invitation email: ${email}" / "Email address"
What it means. Inside the Invite panel, you either see the email the file already carries, or, if there is none, a field asking you to type one.
Why it happened. The panel shows whichever of the two applies to that row.
What to do. If you see the empty field, type the person's email address before saving the choice.
"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."
What it means. A bank debit row for this payer was refused, because nobody can be sent an agreement to sign without an email address, and an agreement nobody can sign would be left behind with no way to complete it.
Why it happened. This refusal only happens on the "send each person the agreement to sign" path. The row reached commit with no deliverable email address for the payer.
What to do. Either add the person's email to your file and upload the bank debit row again in a new batch, or switch the whole batch to the staff declaration path instead, where staff already hold a signed agreement and no email is needed to create it. See The staff declaration.
"No email on file"
What it means. A message that was staged to be sent (a sign request, reminder, or similar) is being held back because the person has no account and no live invitation email to send it to.
Why it happened. The payer behind this message has neither a registered account nor an active invitation carrying an email address.
What to do. Add an email address for that person, then start a new batch to try again.
"The payer's account has not been created yet"
What it means. A staged message cannot be sent because the person it is for does not exist as an account yet.
Why it happened. The payer's row has not been committed, so the invited or registered account behind it was never created.
What to do. Commit the row first. The account is created at commit time, after which the message can be sent in a new batch.
When your own account has no email address
"Your session has no email address, so the import summary cannot be sent."
What it means. The upload cannot finish, because the staff account committing it has no email address for URBI to send the import summary to.
Why it happened. Your own signed-in account is missing an email address.
What to do. Set an email address on your account, then commit again.
Bank debit rows refused because of the payer
These three messages appear when a bank debit agreement could not be created because of something about the payer on that row, rather than about their email address.
"The payer is not an active resident of this unit, so no bank debit agreement was created. Their bank details were kept and can still be used."
What it means. No agreement was created for this row, but the bank details you uploaded were not thrown away.
Why it happened. By the time the row reached commit, the payer was no longer an active resident of the unit.
What to do. Add the person back to the unit, then re-upload the bank debit row in a new batch. The saved bank details will still be there.
"The invited payer for this row is no longer active at this property."
What it means. The invitation behind this row's payer is no longer valid.
Why it happened. The invitation was archived or removed before the row could be committed.
What to do. Send a fresh invitation to the payer, then re-upload the row.
"The unit, billing account or bank details for this row are not resolved."
What it means. One of the three pieces this row needs (the unit, the billing account, or the bank details) was still missing when the batch was committed.
Why it happened. The Units or Payer step for this row was never finished before commit.
What to do. Go back and finish the Units and Payer steps for this row, then retry it.
Problems with the bank details file's payer information
"Unit is required"
What it means. A row in your bank details file is missing its unit.
Why it happened. The unit cell in the uploaded bank details file was left blank.
What to do. Fill in the missing cell in your spreadsheet and upload the file again.
Leaving payer_name blank
What it means. The payer name is optional in both the fee file and the bank details file. A blank cell is not an error. The row uses the unit's current payer, the one person holding the unit's billing account. The bank details upload panel still lists payer_name among its "Required columns". It is optional.
Why it happened. If the unit has no such payer, or more than one, the row cannot choose for itself.
What to do. Make the choice on the Payer step, or fill in the payer name in your file.
"Account holder name is required"
What it means. A row in your bank details file is missing the name of the person who holds the bank account.
Why it happened. The account holder name cell was left blank.
What to do. Fill in the missing cell and upload the file again.
"The bank needs the account holder name in Latin letters. Type it as it appears on the bank account, for example Wang Xiaoming."
What it means. The account holder name on this row contains no Latin letters.
Why it happened. The bank can only read the account holder name in Latin letters.
What to do. Type the name as it appears on the bank account, in Latin letters, and upload the file again.