What exists after you commit, and what you can still change

This article covers two things: exactly what gets created the moment you commit a batch, and where to find each of those things afterwards, then what settings you are still allowed to change once a batch has already committed, including the exact wording you will see if a change is blocked. It is for the staff running or reviewing this import.

What was created, for each successful row

• A lease, or for a condo an owner fee record, on the unit, at the amount your file gave. If the unit already had one and staff chose Update, only its amount changed, and only from the start date forward. The resident, the dates, and every past invoice were left exactly as they were.
• A billing account for that unit, if it did not already have one, with the chosen payer attached as the person responsible for paying it.
• A recurring monthly fee, on the unit's billing day, so the charge repeats automatically every month from now on.
• The first invoice for that fee, if the batch was set to bill the first period on the start date and that date had already arrived by the time you committed. See "The held first invoice" below for what happens when the payer did not exist yet. For a batch where staff declared signed paper agreements, the first bill is always created at commit, dated and due on the first debit date.
• A bank debit agreement, for each row that had bank details, either waiting for the payer to sign it or already recorded as declared by staff, together with the payer's securely stored account details. A single row can never produce more than one agreement. For a declared row, the agreement carries the fee amount as the monthly amount and the first debit date you chose, and a record of the notice is kept (the notice date, who declared it, and when).
• An invited person, for any row where staff chose to invite someone new. In a send-to-sign batch, this person is not actually created, and nobody is emailed, until the messages are sent. Nothing exists for them yet at the moment you commit. In a declared batch, the first bill is created at commit for an invited payer too, and their setup email goes out at commit.
• One prepared message per person, of one of four kinds: a sign request, an acknowledgement notice, a set-up invitation, or an amount change notice. In a send-to-sign batch, none of these are sent yet. Sending is a separate step you choose afterwards.
• One setup email per declared resident, already sent. In a declared batch there is nothing to release for these residents. Their setup email was sent automatically at commit, with the bank, the account ending, the monthly amount, the debit day and the first debit date. No invoice email is sent for the first bill.
• An audit trail entry, for every money change this batch made and for any staff declaration, recording who did it and when.
• A summary email to you, the person who ran the import. See "The summary email you receive" below.

The held first invoice

When the batch bills the first period on the start date, and that date has already arrived, committing raises an invoice for it straight away. For a payer who did not exist yet on that row, that one invoice is held back instead of raised at commit. This does not apply to declared paper agreements: those payers are billed at commit whether or not they have an URBI account yet.

It is raised later, at Send time, once the payer exists, in this order: the payer is created or adopted and linked as the billing account holder, the held invoice is raised, then any parked bank debit rows for that payer are enrolled exactly as they would have been at commit, and finally the messages are prepared so the email that person receives already carries their agreement. If the payer still could not be created at that point, the row is reported on the Send card as "The payer's account has not been created yet" and retried on a later send. The bank details are not thrown away.

Where to find each of them afterwards

• The Send card (" and bank debit batch") on the Bulk Actions tab shows who was committed and when, the four count tiles, and who is on each list. A declared batch whose setup emails have gone out shows as sent, and a sent batch never sends again.
• The bank debit agreement list on the commit result screen, read only.
• The unit's own lease and billing account records. On the unit's Accounting tab, a lease that has not started yet shows as "Starts ", for example when the first debit date is still ahead.
• The unit's PAD Agreements folder, for any signed paperwork staff attached during Review. Staff only.
• The resident portal's billing area, where the payer sees their own agreement and payments. Their signed agreement's PDF is emailed to them.
• Import History, for the batch itself, once it is done.

The summary email you receive

The person who ran the import gets a summary email once the run finishes. Its subject is "Lease import complete" when nothing failed, or "Lease import finished with N rows to review" when at least one row failed. The body opens with "Your lease import for has finished." followed by a table of counts: lease records created, billing accounts created, charge schedules created, and rows needing attention.

If any rows failed, a second table, "Rows that need attention", lists each one by row number, unit, resident, and the reason it failed, so you can see what to fix without opening the import itself. If more than 50 rows failed, the email shows only "Showing the first 50 of N rows. Download the full report from the import tab." with a Review import report button to see the rest. A footnote at the bottom of the email reads "Fee and lease amounts are shown exactly as they were imported."

Bank debit rows waiting for someone with the payments permission

If a member whose payments permission is turned off committed the batch, the fee rows go ahead and the bank debit rows wait. The Send card then shows " bank debit rows are waiting for someone with the payments permission." A member who does have the permission sees a Retry waiting bank debit rows button on the Send card.

What you can still change

While the batch has not committed yet (it is a draft, being resolved, or ready), and after it has committed (committed, or partly committed), you can still change:

• The fee start date
• The start period mode
• The communication date
• The "Send set-up invitations" toggle
• The billing day
• The bank debit consent path, for a batch with bank debit rows

This is what makes the Send card's "Go to Launch settings" link work, and it is how a batch that has already been sent can still move its fee start date. A declared batch does not show the start period, the alignment toggle or the communication date at all: its fee start date follows the first debit date, and its setup emails already went out at commit.

The four situations where you cannot

While the commit itself is running. You will see: "Cannot change launch settings for a batch in status COMMITTING." Wait for the run to finish, then try again.

After a failed commit. The only way out of that state is to use Retry on the commit screen. Launch settings do not open again until the batch has moved past its failed run.

While messages are actually going out. You will see: "Messages for this batch are being sent. Try again once the send finishes." Wait for the send to finish, then try again.

If somebody else changed the batch in the meantime. You will see: "The import batch changed. Refresh and try again." Refresh the page and try your change again.

Side effects of editing after commit

• A scheduled send is cancelled. A declared batch has no send to book, so this applies to send-to-sign batches. If the batch had a send booked for a date, changing any of the schedule fields, the consent choice, or the alignment toggle cancels that booking. You will see "The scheduled send was cancelled because launch settings changed.", and it is recorded in the audit trail. You then need to book or send again.
• Already sent messages are not updated. If messages already went out and you then change the fee start date, a confirmation first asks "Change the fee start date?", warning that "Messages for the fee start date have already been sent. They cannot be recalled." and that "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." You choose Change the date anyway or Keep the current date. If you go ahead, the Send card afterwards shows a standing note: "The fee start date changed to after these messages were sent. Messages already sent were not updated."
• Nothing is ever sent twice. A person who has already been messaged is not messaged again. Rows that get committed after a batch was already sent are reported instead as "N rows committed after this batch was sent. Start a new batch to message them." Sending itself is one way: sent messages cannot be recalled.

Retrying failed rows and reading the error report

For a declared batch, the result screen reads "Import complete" and says the first bill was created for the residents, ready for the first debit on the date you chose, that each invoice is due on the first debit date and is collected by that day's bank file, and that no invoice email was sent. It also says setup emails were sent automatically, one email each. Rows that did not go through are split into two groups:

• Refused. The row broke a rule, so it was not billed. Each one shows the reason and what to do, with Download error report. A refused row cannot be retried. For example: "Fee is not monthly", "Lease splits are active", or a note that a newer bank debit agreement replaced this one and nothing was billed.
• Not processed. These rows can be retried with Retry rows.

If some rows failed to commit, the finished import screen shows Download error report and Retry failed rows buttons alongside the four result tiles. The error report, and the "Rows that need attention" table in the summary email, both list each failed row by row number, unit, resident, and its reason, so you know exactly what to fix before you retry or re-upload.

Retry can itself be blocked. If you press it while the batch is still committing, you will see: "This import is still running. Wait for it to finish before retrying." If you press it on a batch that has no failed rows left, you will see: "This import has no failed rows to retry."

The four result tiles shown once a batch finishes committing.

The Send card for a send-to-sign batch that has committed and is ready to send its messages.

Related articles

• Uploading fees, leases and bank debit agreements in bulk: overview
• What you need before you start
• What your residents and owners see