Sage 50: "Some or all of the transactions cannot be imported
Sage 50 refused some or every row in your transaction import, which usually means bad dates, unknown IDs, or unbalanced entries, not a broken program.
“Some or all of the transactions cannot be imported.” means Sage 50 read your import file and refused part or all of it, row by row. It is not a crash, and usually not a damaged file: it is a validation message. Every row in an import has to satisfy the same rules a manually entered transaction would, and any row that fails is skipped while the rest post. The hedge between “some” and “all” is informative: a partial failure usually means a few bad rows, while a total failure usually means one systematic problem, such as dates or IDs, affecting every row.
Start with the import log, not the file
When an import finishes, Sage 50 can produce a log listing each rejected row and a reason. That log, not the on-screen message, is the real diagnostic. Sort the rejections by reason before changing anything: one repeated cause explains most failures of this kind, and fixing it clears many rows at once. An empty or nonsensical log is itself a clue, covered below.
Check dates against the periods that are open
Sage 50 organizes every company by fiscal year and posting period, and it will not post a transaction dated outside the periods that are open. This is the most common cause of a partial import: rows inside the open periods post, and rows dated in a prior year, a future period, or a locked period are refused. Compare the earliest and latest dates in your file against the fiscal years that exist in the company. Whether a closed period can be reopened, and what that does to prior reports, depends on the file, so treat it as a decision rather than a quick fix.
Match every ID exactly
Each row must reference records that already exist: account IDs from the chart of accounts, customer and vendor IDs from their ledgers, item IDs where rows touch inventory, and job or project IDs if you use them. One mismatched ID rejects the row. Look for IDs that appear identical but differ by a trailing space, a leading zero, or a character altered when the file passed through a spreadsheet. Sage 50 also keeps certain system-maintained accounts that cannot be posted to directly; rows aimed at those are refused however well-formed they are.
Check the rows themselves
The remaining frequent causes are structural: a journal entry whose debits and credits do not balance, a missing required field, a duplicate invoice or reference number where the company enforces uniqueness, or text in an amount or quantity column. Which rules apply depends on the transaction type and on how the file was prepared. The reliable way to get the layout right is to export a sample of the same transaction type from the same company and match that structure exactly.
Handle the partial import carefully
If some rows posted, re-running the whole file duplicates them. Either correct and re-import only the rows the log rejected, or restore the backup taken before the import and start over. If no backup was taken first, make one now, before any further attempts.
When the message is a symptom of damage
If the log is empty or nonsensical, if the same file imports cleanly into a fresh sample company but fails in yours, or if other operations have started misbehaving, the data file itself may be damaged and the import is simply where it surfaces. Further import attempts will not help; the file needs professional repair first. We evaluate Sage 50 files at no charge.
If this appeared during a conversion to QuickBooks
The same message can appear when a conversion tool moves Sage 50 data into QuickBooks. There the rejected rows are usually transaction types the converter cannot map, such as certain inventory and job-related entries, or damage sitting in the Sage data. A direct Sage 50 to QuickBooks conversion reads the data file instead of replaying an import, which sidesteps the row-by-row validation that rejected them.
The practical next step: open the import log, count the rejected rows, and read the first reason listed. That line almost always tells you which section above applies. If it does not, or if the log will not open at all, get a free evaluation of the file before re-importing anything.