Import Errors and What They Mean
Use this reference when a general ledger import has failed, refused an action, or is showing an outcome you did not expect. It answers, for every case, whether any money has posted and whether your...
Last updated
Use this reference when a general ledger import has failed, refused an action, or is showing an outcome you did not expect. It answers, for every case, whether any money has posted and whether your books are safe right now. For everyday tasks (resuming, discarding, reversing) read managing-import-history.md instead.
Read this first: four rules that decide whether your books are safe
- Nothing posts until you commit. Uploading, mapping, staging, and re-running matching never touch the general ledger. Every failure in those stages leaves your books exactly as they were.
- A batch never reaches Committed while any entry is in error. If even one entry failed, the batch ends Failed, not Committed. There is no state where the badge says the import finished but some of it quietly did not.
- A refused action changes nothing. When URBI refuses to clear or re-stage a batch, it refuses before it writes anything. The batch is identical afterwards.
- Retry never posts anything twice. A retry reprocesses every entry that is still part of the import and has no live journal entry: an entry that already holds one is never posted again. An entry whose earlier journal entry was voided, whether by a failed reversal or by a person, counts as having no live entry, so retry posts it again rather than skipping it. To leave such an entry out on purpose, exclude it before you retry.
The single most reliable answer to "did money post" is the Journal entries posted figure on the failure card. It counts what is live in the general ledger.
Part 1: Batch states that mean something went wrong
Failed
What you will see. The batch shows the Failed badge in Import History. Opening it shows either the Commit failed card or the N of M entries did not post card, with a Journal entries posted count, a Failed at phase value, and an Error detail message.
What it means. The commit started and stopped before every entry was posted. It is a stopped import, not an undone one.
Has money posted? Read the Journal entries posted count.
- If it reads 0: nothing posted. The card says so directly: No journal entries were posted, so your general ledger is unchanged. Your books are safe and untouched.
- If it reads more than 0: that many journal entries are live in your general ledger and are real. The rest are not. Your books are correct as far as they go, but this import is incomplete, so your trial balance will not yet match your source file.
What to do next. Fix whatever the Error detail names (the cases below tell you what each one means), then select Retry import. If retrying does not get you there, select Reverse and start over with a corrected file.
How to avoid it next time. Most commit failures come from something that changed between staging and committing: accounting being turned off, a plan change, a permission change, or the uploaded file being removed. Committing shortly after you finish resolving avoids nearly all of them.
Reversed
What you will see. The batch shows the Reversed badge. No actions are offered on it.
What it means. Somebody deliberately rolled this import back. That is a decision, not a failure.
Has money posted? It did, and then it was undone. Reversal journal entries were posted against the original ones, the originals were marked void, and any fiscal periods this import locked were re-opened. Your books are safe: they are back where they were before the import, with a full record of both the import and its reversal.
What to do next. Nothing, unless you still need the data in. If you do, correct your source file and start a fresh import.
How to avoid it next time. Reversal is often the right answer, so there is nothing to avoid. Where it is worth avoiding, resolving carefully at Review & Balance before committing is what does it.
Failed against Reversed, in one line each
- Failed means the import tried to post and stopped. Whatever posted before it stopped is still live, and the import is still finishable with Retry.
- Reversed means everything the import posted has been undone on purpose, with reversal entries recorded. It is finished and cannot be re-run.
Nothing was deleted in either case.
Part 2: Per-entry outcomes
Four different things can happen to a single entry. Only the first is a problem.
An entry that errored
What you will see. The entry is listed under Failed entries and their reason on the partial-failure card, with its entry number, description, date, and its own stored reason. The Entries in error tile counts them.
What it means. URBI tried to post this specific entry and could not.
Has money posted? Not for this entry. Its money is not in your general ledger. Other entries in the same batch may have posted; the counts on the card tell you exactly how many.
What to do next. Read the reason stored against the entry, correct the cause, then select Retry failed entries. Only the errored entries are reprocessed.
How to avoid it next time. These are usually data problems in one row of the source file. Resolving the flags at Review & Balance before committing catches most of them earlier.
An entry that was skipped
What you will see. The entry counts as skipped and does not appear in the work to resolve.
What it means. One of two things. Either the entry has a line in a currency other than the property's own currency, so URBI will not convert it and guess, or somebody skipped it during review.
Has money posted? No, and it never will as part of this import. This is not an error, and your books are safe. It is a deliberate omission.
What to do next. Usually nothing. A skipped entry needs no account, vendor, or unit resolution and never blocks Commit Import. If it genuinely belongs in your ledger, post it by hand as a journal entry, or correct the currency in the source file and import again.
How to avoid it next time. Where your file mixes currencies, split the foreign-currency activity out before uploading, so you decide the treatment rather than having the rows set aside.
An entry you excluded
What you will see. The entry is counted as excluded, for example N entries excluded (closed period) on the review summary. If you excluded it in error, Include again brings it back.
What it means. You told URBI to leave this entry out. Nothing else.
Has money posted? No, by your own instruction. Your books are safe.
What to do next. Nothing, unless you changed your mind, in which case select Include again before committing.
How to avoid it next time. Row-level Exclude now asks for confirmation before it applies, so a stray click no longer removes an entry silently.
An entry blocked by a closed accounting period
What you will see. The entry appears under Held entries with a lock icon and the label Existing closed - excluded. The gate above the list reads N rows land in an existing closed period. Exclude them to continue.
What it means. The entry is dated inside a fiscal period that is already closed. URBI will never re-open a closed period by itself, so it holds the entry rather than posting into your closed books.
Has money posted? No, and the commit will not even start while these are outstanding. Your closed periods are safe: that is the whole point of the block.
What to do next. Decide what the entry should be. If it belongs in the closed period, exclude it here and handle the period through your normal period-reopening process, deliberately. If it is simply misdated, correct the date in the source file and import again. To get past this screen, every held closed-period entry must be excluded.
How to avoid it next time. Set the cutover date so that pre-cutover activity folds into the opening balance rather than arriving as dated detail inside closed periods.
These four are not the same thing. Errored means URBI tried and failed. Skipped and excluded mean the entry was set aside, by rule or by you. Closed-period means URBI is protecting books you already closed. Only errored calls for a fix.
Part 3: The partial commit, where some entries posted and some did not
What you will see. A card headed N of M entries did not post, with two tiles (Journal entries posted and Entries in error), a list of the failed entries with their individual reasons, a What happened explanation, and two buttons: Retry failed entries and Reverse batch.
What it means. The commit ran, most of the file went in, and some entries did not.
Has money posted? Yes, some. The Journal entries posted count is live in your general ledger and is correct accounting. The entries listed as failed are not in the ledger at all. There is no half-posted entry: an entry is either fully posted with both sides, or not posted.
What to do next.
- Read the stored reason on each failed entry. They are frequently all the same cause.
- Fix the cause.
- Select Retry failed entries. It reprocesses only the failed ones and never re-posts an entry that already holds a journal entry.
- If retrying will not clear it, select Reverse batch. That rolls back everything this import posted, including the entries that succeeded, and lets you start over with a corrected file.
Why the batch stays Failed rather than Committed. This is deliberate and it protects you. Committed is URBI's statement that the whole file is in your ledger. If a batch with failed entries were marked Committed, the badge would be telling you your books are complete when they are not, and the difference would surface later as an unexplained variance. Leaving it Failed keeps the discrepancy visible and keeps both Retry and Reverse reachable. It is not a bug, and you do not need to force the badge to change.
How to avoid it next time. Clear every flag at Review & Balance first, and commit when nobody else is changing the property's accounting settings.
Part 4: Refusals when re-running matching or continuing over a staged batch
These all come from the same safety step: before URBI clears a staged batch, it checks that clearing it is safe. Every refusal here happens before anything is written. In every one of these cases, no money has posted as a result of your action, nothing has been cleared, and your batch is exactly as it was.
Somebody else changed the batch since you opened it
What you will see. The action is refused, and on the mapping step the screen tells you: This batch changed somewhere else and has been reloaded.
What it means. Another person, or another browser tab of yours, changed this batch after your screen loaded. URBI will not apply your instruction on top of a version you have not seen.
Has money posted? No. Nothing at all was written. Your books are safe and the batch is untouched.
What to do next. Let the screen reload, review the current state of the batch, and repeat the action if you still want it.
How to avoid it next time. Agree who is driving an import before it starts, and avoid keeping the same import open in two tabs.
Another staging run is already going
What you will see. The re-stage or re-run does not start, and the batch remains as it was.
What it means. A staging pass for this batch is already running. URBI allows one at a time.
Has money posted? No. Staging never posts. Your books are safe.
What to do next. Wait for the run in progress to finish, then look at the result before starting another. If it appears stuck, use the guidance at the end of this article.
How to avoid it next time. Give a re-run time to finish before pressing anything again. Double-pressing is the usual cause.
The import already has posted entries, so it must be reversed first
What you will see. The message, word for word: This batch already has posted entries and must be reversed first. The panel adds: Reverse the posted entries before re-running matching. There is no Retry on this one, because retrying cannot help.
What it means. Part of this import is already in your general ledger. Re-running matching throws away the staged work and rebuilds it, which would orphan the entries that already posted. URBI refuses rather than let that happen.
Has money posted? Yes, and that is precisely why you are seeing this message. What posted is still correct and still in the ledger. Nothing has been cleared, and your books are safe.
What to do next. Choose one:
- Retry the import instead, if you simply want to finish it. Retry works on posted batches and never re-posts what is already live.
- Reverse the batch if the matching decisions really do need redoing. Once it is reversed, start a fresh import from the corrected file. A reversed batch does not offer Re-run matching.
How to avoid it next time. Re-run matching belongs before you commit, not after. If matching looks wrong, re-run it while the batch is still Draft, Resolving, or Ready.
Entries still need a decision
What you will see. Retry is refused. The message names how many, for example: 3 entries still need a decision before this import can be committed. Open the import, decide or exclude them, then retry.
What it means. One or more staged entries have not been resolved or excluded yet, so URBI will not post the batch while an unresolved line is still inside it.
Has money posted? No. This is checked before Retry does anything. Your books are safe and the batch is unchanged.
What to do next. Open the import, decide or exclude the entries the message counts, then select Retry again.
How to avoid it next time. Clear every flag at Review & Balance before a batch is left to sit as Failed, so a later retry never runs into leftover decisions.
You no longer have permission
What you will see. The action is refused. On a commit the Error detail reads: You no longer have permission to post journal entries for this property.
What it means. Your permission to post journal entries for this property was removed or was never granted. URBI denies by default here: if there is no explicit permission, there is no access.
Has money posted? Not from this attempt, which stopped before doing anything. If the batch had already posted entries from an earlier attempt, those are still live and still correct. Your books are safe.
What to do next. Ask an administrator to restore your permission to post journal entries for this property, then repeat the action. If the import is time-sensitive, someone who still has the permission can complete it.
How to avoid it next time. Confirm your access before starting a large import, especially just after a staffing or role change.
Accounting is no longer enabled, or the plan no longer covers importing
What you will see. One of these, word for word, in the Error detail:
- Accounting is no longer enabled for this property.
- The property's accounting plan no longer permits history import.
- Could not verify the property's accounting subscription.
What it means. In order: accounting was switched off for this property; the plan the property is on does not include history import; or URBI could not check the subscription at all, and refuses to proceed on an unverified answer rather than guessing.
Has money posted? Not from this attempt. These checks run before any posting in the run. Anything posted by an earlier attempt is unaffected and still correct. Your books are safe.
What to do next. For the first two, have the property's accounting settings or plan sorted out, then select Retry import. For the third, wait a few minutes and retry. If it repeats, get help rather than retrying in a loop.
How to avoid it next time. Check that accounting is enabled and the plan is right before you upload, not after you have resolved several hundred entries.
The batch could not be found
What you will see. The action is refused with Import batch not found.
What it means. The batch no longer exists, or it belongs to a different property from the one you have open. URBI returns the same answer either way, on purpose, so nothing is revealed about another property.
Has money posted? No. Nothing happened. Your books are safe.
What to do next. Reload Import History and check you are on the right property. If the batch was discarded by someone else, it is gone and you should start a fresh import.
How to avoid it next time. Work from Import History on the property you intend, rather than from an older link or bookmark.
Part 5: File problems
The file lives in URBI's storage from the moment you upload it. Re-staging and re-running both read it again, so a file that has gone missing surfaces later, not at upload.
The uploaded file cannot be reached, downloaded, or read
What you will see. One of these on the failure card, or as the reason under it:
- Can't find the uploaded file. It may have been removed from storage. Nothing has been cleared, and your current staged work is untouched. Upload the file again from Import History, or press Back to start a new import.
- A reason beginning could not access source file, could not download source file, or could not stat source file (the last two carry a technical code in brackets for support).
What it means. URBI went back for the file it stored at upload and could not get it: it is gone, or storage did not answer.
Has money posted? No. This happens during staging, which never touches the general ledger. Your books are safe, and in this case your existing staged decisions are safe too: the failure happens before anything is cleared, and the screen tells you so.
What to do next. Upload the file again from Import History, or select Back and start a new import. Do not redo your matching work first: it is still there.
How to avoid it next time. Keep the source file to hand until the import is committed, and finish an import reasonably close to when you uploaded it.
Part 6: Setup problems
The Opening Balance Equity account could not be prepared
What you will see. The Commit failed card with the Error detail: Could not ensure the Opening Balance Equity (3050) account.
What it means. Pre-cutover activity folds into a single opening-balance journal entry, and that entry needs the property's Opening Balance Equity GL account. URBI could not confirm the account, so it stopped rather than post opening balances against the wrong GL account.
Has money posted? Not from this attempt: the check runs before this attempt posts anything. If an earlier attempt posted entries, the Journal entries posted tile shows how many, and those are still live and correct. Your books are safe.
What to do next. Check the property's chart of accounts for its system Opening Balance Equity account, then select Retry import. If the account is missing or has been altered, get help before retrying: this one is about your chart of accounts, not about the file.
How to avoid it next time. Leave the system Opening Balance Equity GL account alone. Renaming or renumbering system accounts is what usually breaks this.
The file belongs to a different property
What you will see. The Commit failed card with the Error detail: Import source file path does not match this property.
What it means. The stored file for this batch is not filed under the property you are committing into. URBI refuses to post one property's ledger data into another property's books.
Has money posted? No. This check runs before any posting. Your books are safe, and so are the other property's.
What to do next. Do not retry, because retrying will refuse again. Start a fresh import on the correct property and upload the file there. If you believe the file really does belong to this property, get help: this is not something to work around.
How to avoid it next time. Confirm which property is selected before uploading, particularly when you are importing several properties in one sitting.
Part 7: Two situations that look alarming and are not
A re-run that failed before clearing anything
What you will see. The failure card headed Re-run matching did not finish, with the line: Nothing has been cleared. Your current staged work is untouched. A Retry button is offered.
What it means. The re-run stopped at the very first stage, usually because the stored file could not be read, before it removed any of your decisions.
Has money posted? No, and nothing was cleared either. Every unit pick, vendor assignment, and plain mark you made is still there. Your books and your work are both safe.
What to do next. Fix whatever the reason names, most often by re-uploading the file, then select Retry. Do not start again from scratch, and do not redo the matching: the screen is telling you it is all still there, and it is correct.
For comparison, when a re-run fails after the clear, the card says something different: The decisions this batch cleared to re-run are gone, and the new staging pass did not complete. The batch stays recoverable: nothing else was changed. That one does mean the matching decisions need redoing, but still no money moved, and still nothing else about the batch changed.
How to avoid it next time. Nothing to avoid. This is the safety design working, and the wording is there so you do not throw away good work.
The Vendors step shows no vendors at all
What you will see. The Vendors step reads No vendors on this batch, with the explanation that every candidate, including entries such as system markers and reverse bank interest, is a plain ledger line, and that the batch will commit with no vendor attached to any of these lines. A Continue to Review button is offered.
What it means. URBI looked at every outgoing name in the file and concluded that none of them is a vendor. They are bookkeeping markers, reversals, or payers, and payers belong on the Units step, not here.
Has money posted? Nothing has posted yet, and nothing is missing. Every line is still in the import and will still post. A line without a vendor is a perfectly normal ledger line.
What to do next. Select Continue to Review. An empty vendor list is a finished vendor list.
How to avoid it next time. Nothing to avoid. Not making a vendor out of a bookkeeping marker just to clear a list is the correct outcome, and it is why Mark as plain exists. See choosing-vendors-and-marking-plain-ledger-lines.md.
Part 8: When to stop and get help instead of retrying
Retry is safe. It never re-posts a journal entry that is already live, so pressing it again cannot double your books. It is still the wrong move in these cases:
- The same error detail comes back twice in a row unchanged. Nothing about the batch changed between the attempts, so a third attempt will not change it either.
- The error names your chart of accounts or your subscription (the Opening Balance Equity account, accounting being disabled, the plan not permitting import). These need somebody to change a setting, not another attempt.
- The error says the file belongs to a different property. Retrying will refuse forever. That import needs to be started on the correct property.
- The stored file cannot be found and re-uploading does not fix it.
- A staging run has been in progress for a long time and nothing is moving. Do not stack more attempts on top of it.
- The counts do not add up to you. If Journal entries posted does not match what you expect for the file, stop and have it looked at before reversing or retrying. Both actions are recoverable, but a clear picture first is cheaper than either.
When you ask for help, quote the batch reference from the row, the Failed at phase value, and the Error detail exactly as shown. Those three identify the run precisely.