Problems with amounts, fees and dates
This article explains every message you might see about money amounts, fee start dates and billing days while using the bulk upload wizard, from the file you upload through to the moment the batch...
Last updated
This article explains every message you might see about money amounts, fee start dates and billing days while using the bulk upload wizard, from the file you upload through to the moment the batch commits. It is for property managers, building staff and board members. Read the section that matches what you are seeing. Where a message means money did not move, that is said plainly. Where it means a charge was created, that is said plainly too, so you are never left guessing whether something has been billed.
Problems with the amounts you enter
These messages appear on the Review step, in the Issue cell for the row, and are repeated in the error report and the summary email if the row is not fixed before commit.
"rent amount cents must be whole cents (no decimals)"
The same wording appears for condo fee cents, reserve contribution cents, security deposit cents, escalation amount cents, parking amount cents and add on amount cents.
What it means. The amount in that cell has a decimal point, a letter, or something else that is not a plain whole number.
Why it happened. Every amount in the upload is stored in cents, not dollars, so it must be a whole number. $412.50 is written as 41250, not 412.50.
What to do.
- Open your file and find the cell named in the error.
- Convert the amount to cents by multiplying the dollar figure by 100.
- Remove any decimal point, currency symbol or letter.
- Re-upload the file.
"rent amount cents cannot be negative"
The same wording appears for every other cents field named above.
What it means. The amount in that cell is below zero.
Why it happened. A negative number was typed or pasted into an amount column.
What to do. Change the amount to zero or a positive whole number of cents, then re-upload.
"Amounts must be whole cents" / "Amounts cannot be negative"
What it means. These are the same two rules above, checked a second time, later in the process, shortly before the row is committed.
Why it happened. A row reached commit still carrying a decimal or negative amount. This can happen if the row was corrected in the file but the corrected file was never re-uploaded.
What to do. Re-upload the corrected file and confirm the row's Issue cell is clear before you commit.
"rent amount is required on a RESIDENTIAL_RENTAL row"
What it means. A rental row is missing its rent amount.
Why it happened. The rent_amount_cents cell for that row is blank.
What to do. Fill in the rent amount for that row, in cents, and re-upload.
"condo fee is required on a CONDO_OWNERSHIP row (0 is allowed)"
What it means. An owner-fee row is missing its condo fee amount.
Why it happened. The condo_fee_cents cell for that row is blank. A fee of zero is a valid entry;
an empty cell is not.
What to do. Enter the fee for that row, using 0 if the unit genuinely has no condo fee, and re-upload.
"rent amount does not belong on a CONDO_OWNERSHIP row"
What it means. An owner-fee row is carrying a rent amount, which does not apply to that kind of row.
Why it happened. A rent amount was entered in a row marked as condo ownership rather than residential rental.
What to do. Delete the rent amount cell on that row, then re-upload.
"condo fee cents does not belong on a RESIDENTIAL_RENTAL row" / "reserve contribution cents does not belong on a RESIDENTIAL_RENTAL row"
What it means. A rental row is carrying a condo fee or reserve contribution amount, which does not apply to that kind of row.
Why it happened. The same mismatch as above, the other way round.
What to do. Delete those cells on the rental row, then re-upload.
"end date applies to leased rows only, not a CONDO_OWNERSHIP row"
What it means. An owner-fee row has an end date filled in, but ownership fees do not have an end date.
Why it happened. A date was entered in the end date column on a condo ownership row.
What to do. Clear the end date on that row, then re-upload.
"billing day must be a whole number from 1 to 28"
What it means. The billing day you entered for a row is outside the range the system accepts.
Why it happened. The value is not a whole number, or it is 0, negative, or higher than 28.
What to do. Use a day from 1 to 28. If your property bills on the last day of the month, see Choosing your dates and launch settings for how end-of-month billing is set up; it is not entered as a day number here.
"escalation percent must be a non-negative number"
What it means. The escalation percent for a row is negative, or is not a number the system can read.
Why it happened. A negative value, or text, was entered in the escalation percent cell.
What to do. Use a non-negative number, for example 3 for a 3 percent increase, then re-upload.
The fee start date and the ten day rule
This is the rule that most often stops people on the Launch settings step, so it gets its own section here as well. Whether the rule applies, and which dates it is counted between, depends on the kind of batch you are launching.
- Bank debit rows where each person signs. The communication date must be at least 10 days before the fee start date. The rest of this section explains it.
- Bank debit rows with a staff declaration (signed paper agreements). There is no communication date. The fee start date is locked to the first debit date, and the 10 days are counted from the date residents were told (the notice date) to the first debit date. See The fee start date on a batch with signed paper agreements.
- Fees only. There is no 10 day rule. See Fees only batches have no ten day rule.
- Bank details only. There is no fee start date, start period or communication date at all. Launch settings shows only the bank debit agreement choice and the "Send set-up invitations" switch, with the line "Fees already running for these units are not changed by this upload."
Why it exists. Anyone being asked to review their bank details and sign a bank debit agreement needs real time to notice the email, read it, and sign, before any money is scheduled to move. Ten days is the amount of runway the wizard requires so nobody is rushed into signing something at the last minute. On a batch with signed paper agreements the same ten days protect residents differently: they must have been told about the first debit at least ten days before it.
"The date every new or changed fee takes effect. Segment 3's communication date and this date must be at least 10 days apart."
What it means. This is the helper text under the fee start date field on a batch where people sign their agreements. It tells you the fee start date and the communication date (further down the same screen) must sit at least ten days apart. The words "Segment 3" are leftover wording. They only mean the communication date on this same screen. On a fees only batch the same words can still appear, but there is no ten day rule there.
Why it happened. This text is shown under the field whether or not there is a problem yet. A batch with signed paper agreements shows different text, explained below.
What to do. Choose the date the new or changed fee should begin, keeping the ten day gap in mind.
"Communication date must be at least ten days before the fee start date."
What it means. The communication date you chose is too close to the fee start date. The date picker also says "Latest allowed: 10 days before the {fee} start date."
Why it happened. The gap between the two dates is under ten days.
What to do. Move the communication date earlier, or move the fee start date later, so a full ten days sits between them.
"Bank debit messages must go out at least 10 days before the {fee} start date. Move the {fee} start date to send them."
What it means. Your fee start date is now so close that there is no valid communication date left to choose at all. No bank debit message can go out for this batch as things stand.
Why it happened. The fee start date is fewer than ten days away.
What to do. There is no override and no way to shorten the ten days. Move the fee start date later, far enough into the future that a full ten days fits before it.
"Bank debit messages need at least ten days before the fee start date. Move the fee start date to send them."
What it means. The same rule as above, caught at the moment you tried to send, rather than while you were still on the Launch settings step.
Why it happened. The fee start date became too close to today between when the batch was set up and when you tried to send.
What to do. Move the fee start date later, on the Launch settings step, then try sending again.
"The {fee} start date is less than 10 days away"
What it means. This is the reason recorded against an individual message when it cannot be sent because of the ten day rule.
Why it happened. Same condition as above, shown per message rather than as a general banner.
What to do. Move the fee start date later. The held message will become sendable once the gap is restored.
The fee start date and communication date fields on a batch where people sign, with the ten-day helper text and a blocked communication date.
Fee start date
September 25, 2026
The date every new or changed fee takes effect.
Communication date
Blocked
Bank debit messages must go out at least 10 days before the fee start date. Move the fee start date to send them.
Fees only batches have no ten day rule
"No bank debit rows in this batch, so there is no 10-day rule. A {fee} can start within 10 days of the communication date."
What it means. Your batch has fees only. Nobody is being asked to sign a bank debit agreement, so URBI does not require ten days between the communication date and the fee start date.
Why it happened. This caption is shown on Launch settings when the batch has no bank debit rows.
What to do. Nothing. The communication date still cannot be before today. Amount change notices, and set-up invitations if you turned that switch on, still wait on the Send card until you send them.
The fee start date on a batch with signed paper agreements
When you choose "I already hold signed agreements (staff declaration)", Launch settings hides the start period choice, the toggle for starting bank debits on the fee start date, and the communication date. The fee start date and the ten days work as follows instead.
"Same as the first debit date for signed paper agreements. Change the first debit date below to move it."
What it means. You cannot pick a fee start date on its own for this batch. It is always the same as the first debit date.
Why it happened. A batch with signed paper agreements has one date that matters, the first debit date, which you choose on the "Signed paper agreements" card.
What to do. To move the fee start date, change the first debit date on that card.
"Each resident gets one setup email automatically when the import commits. There is no communication date to set for a declared batch."
What it means. This line takes the place of the communication date. Nothing is held on the Send card for you to send. The setup email goes out when the import commits, and the first bill carries no invoice email.
Why it happened. Residents on this path do not sign anything in URBI, so there is nothing to schedule.
What to do. Nothing.
"6 days between the notice and the first debit. The notice needs at least 10 days."
What it means. On this path the ten day rule is counted from the notice date, the date residents were told about the first debit, to the first debit date. Your dates are too close. The card also says "Choose a first debit date at least 10 days after the notice date." and "Earliest first debit date for a notice on 1 December 2026: 11 December 2026."
Why it happened. The first debit date is less than 10 days after the notice date.
What to do. Choose a first debit date on or after the earliest date the card shows. Staff cannot get past this rule. Only URBI can allow a one-time shorter notice, after which everyone sees "URBI allowed a shorter notice." The notice date also has to be today or earlier ("The notice date cannot be after today.") and before the first debit date ("The notice date must be before the first debit date.").
"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."
What it means. The first debit date you picked cannot be used.
Why it happened. The date is not a Canadian business day, or the bank file for that date has started building. The bank file for a debit date is built at 7:00 AM Toronto time on that date, Monday to Friday.
What to do. Pick a later date. For the full list of rules on these two dates, see Problems with the notice date and the first debit date.
The fee start date must land on the billing day
"Future fee start date must fall on the billing day, day (the property's billing day) of that month."
What it means. You chose a future date for the fee to start, but it does not fall on the day of the month your property bills on.
Why it happened. The property has a fixed billing day, for example the 1st. A future fee start date must land exactly on that day. This applies where you choose the fee start date yourself. On a batch with signed paper agreements the fee start date is set from the first debit date, so change the first debit date instead.
What to do. Move the date to the property's billing day. If you want a date that falls mid-cycle, choose today's date instead of a future one; only a future date is held to the billing day.
"Future fee start date must fall on the billing day, which is the last day of the month."
What it means. The same rule as above, for a property whose billing runs to the end of the month rather than a fixed day number.
Why it happened. A future date was chosen that is not the last day of the month.
What to do. Move the date to the last day of that month.
"{fee} start date must be on the billing day"
What it means. This is a reminder in the wizard's "Still need" list, telling you the date problem above is still unresolved.
Why it happened. Same condition, shown in the footer list of everything left to fix on this step.
What to do. Fix the date as described above.
Choosing when the new fee starts
These two cards are not shown on a batch with signed paper agreements, where the fee start date follows the first debit date, or on a bank details only batch.
"Start period mode *"
What it means. This is the required heading over two cards. You must choose one before you can continue.
Why it happened. This heading always shows on the Launch settings step; the asterisk marks it as required.
What to do. Read the two cards below and pick one.
"Charge the first period on the start date" / "The {fee} start date's charge covers the full period, even if the date falls mid-cycle."
What it means. If you pick this card, the unit is charged the full new amount for the current billing period, even if the fee start date falls partway through it. Nothing is split or reduced for the partial period.
Why it happened. This is always shown as one of the two choices.
What to do. Choose this if you want the new amount applied in full starting this period.
"Start at the next billing date" / "Skip the partial period; the first charge lands on the next full billing date instead."
What it means. If you pick this card, the current period is left alone and the new amount takes effect starting the next full billing period.
Why it happened. This is always shown as the second of the two choices.
What to do. Choose this if you would rather wait for a clean, full period before the new amount applies.
"{Fees} are never prorated. A backdated start is not offered here."
What it means. There is no third option that splits a partial period into a smaller amount, and you cannot choose a fee start date that has already passed.
Why it happened. This caption always shows under the two cards.
What to do. Nothing to fix. It is a statement of how the two choices work.
"Start period mode" (in the "Still need" list)
What it means. This is a reminder that you have not yet picked one of the two cards.
Why it happened. No start period mode was chosen.
What to do. Pick one of the two cards described above.
"BACKDATE_PAID is not available for lease imports."
What it means. A request was sent to save a start period mode this wizard does not offer for lease imports.
Why it happened. This should not happen from normal use of the wizard's two cards. If you see it, contact your URBI administrator.
What to do. Contact your URBI administrator.
If the wizard still will not let you continue
"{fee} start date" (in the "Still need" list)
What it means. You have not yet chosen a fee start date.
Why it happened. The field was left empty.
What to do. Choose the date the new or changed fee should take effect.
"Set both fields to continue"
What it means. The step is not ready to move forward, and the wizard did not name specific missing fields.
Why it happened. Both the fee start date and the start period mode still need attention.
What to do. Fill in the fee start date and choose a start period mode, then continue.
"Fee start date and start period mode must be set before committing."
What it means. You reached the commit step, but the batch still has no fee start date or no start period mode recorded against it. Nothing has been committed and no money has moved.
Why it happened. The batch's stored settings are missing one or both of these values.
What to do. Go back to Launch settings, fill in both fields, and try committing again.
Changing the fee start date after messages have already gone out
"Change the {fee} start date?" / "Messages for the ${oldDate} {fee} start date have already been sent. They cannot be recalled." / "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."
What it means. This is a confirmation window. You are being warned before you change a fee start date on a batch whose messages have already gone out to residents.
Why it happened. You tried to change the fee start date after the batch's messages were sent.
What to do. Read the two buttons carefully: "Change the date anyway" and "Keep the current date". Only choose to change the date if you accept that the emails already sent cannot be corrected or recalled; the app and the sign page will show the new date going forward, but the email a resident already opened will still show the old one.
"The {fee} start date changed to ${date} after these messages were sent. Messages already sent were not updated."
What it means. This is a standing warning shown on the Send card afterward, so the mismatch is never a surprise later.
Why it happened. You confirmed a fee start date change on a batch whose messages already went out.
What to do. Tell the affected people directly about the new date, or start a new batch if the change is significant enough to need fresh messages.
What residents see when an amount changes
"Your {fee} is changing: ${propertyName}" (email subject) / "Your monthly {fee} is changing."
What it means. This is the notice a resident receives when their amount changes.
Why it happened. A row using the Update choice committed with an amount different from what that person was already paying.
What to do. Nothing to fix. This confirms the resident was told.
"The amount did not change"
What it means. No notice was sent to this person, because their amount is exactly the same as before.
Why it happened. Every update for that person kept the same amount.
What to do. Nothing. No notice is needed, and none was held back due to a problem.
"The previous amount was not recorded"
What it means. A change notice could not describe what changed for this person, because the amount they were paying before is not on record.
Why it happened. The commit did not record a before-amount for that row, so there is nothing to compare the new amount to.
What to do. Contact that person directly to explain the change, since an automatic notice cannot be generated for this row.
"Row ${n}: the previous amount was not recorded, so the change cannot be described."
What it means. This is the same message as above, shown per row, as the reason behind the Held back line.
Why it happened. Same condition, recorded for that specific row.
What to do. Same as above, contact that person directly.
When the billing account still has no holder
"The billing account still has no holder, so the invoice has nobody to be addressed to."
What it means. An invoice for this unit was ready to be created, but there is not yet a person attached to the billing account to name on it. No invoice has been raised for this row yet, and no money has moved.
Why it happened. This happens on rows where the payer did not exist as a person in URBI when the batch was committed, so they were invited rather than chosen from people already on the unit. In that situation, the first invoice is deliberately held back rather than raised at commit. It is meant to be raised later, at Send time, in order: the payer's account is created, they are linked to the billing account as its holder, and only then is the invoice raised. If this message appears, that account-linking step had not finished yet when the invoice was attempted. See What exists after you commit, and what you can still change for the full order this happens in.
What to do. This normally resolves itself the next time the batch is sent, once the payer's account exists and is linked. If it keeps appearing after a send, contact your URBI administrator.
This applies to batches where people sign. On a batch with signed paper agreements, the first bill is created when the import commits for every payer, whether or not they have an URBI account.
What you will see when the import finishes
"Charge schedules created" / "{Leases} created or updated" / "Billing accounts created" / "Rows skipped or failed"
What it means. These are the four result tiles shown on the commit success screen, and again in the summary email you receive. They count exactly what the commit did.
Why it happened. These always show after a leases commit finishes.
What to do. Nothing to fix if the numbers match what you expect. If "Rows skipped or failed" is higher than zero, open the error report to see the reason for each one; the reason will be one of the messages in this article or in Errors matching units and payers.
"{fee} and {lease} amounts are shown exactly as they were imported."
What it means. This is a footnote on the import summary email, confirming the amounts listed in the email match exactly what was in your uploaded file.
Why it happened. This always shows on the summary email.
What to do. Nothing to fix. Use it to double check your file matched what you intended.