Allocadia scheduled import failed: "Invalid date — date outside acceptable range"

This error means a date in your import file uses a year outside Allocadia's accepted range (1900–2050). Here's how to find the row and fix it.

What this answers:

• Why a scheduled import returns "Invalid date — date outside acceptable range"
• How to find the bad row in your source file and correct it
• What to do if the row looks correct but the error keeps coming back

What the error looks like

When a scheduled import (PO, Actual, or Line Item) fails on a date value, you'll see an error like this in the run notification:

Invalid date 'YYYY-MM-DD' in column '<ColumnName>__<Customer>_', row N (date outside acceptable range).

The bad row stops the entire run, so nothing in the file is loaded until it's corrected and re-submitted.

Why this happens

Allocadia accepts dates with a year between 1900 and 2050. Any date with a year outside that range is rejected by the import.

In almost every case, the cause is one of these two:

1. A typo in the source data. Someone keyed 3020 instead of 2030, or 1019 instead of 2019 — a finger-slip on the leading digit. The value still looks like a date, but the year lands far outside the accepted range.
2. A date-format mismatch on the import template. The column's parse format in your import schedule doesn't match the way dates are actually written in the file. Common examples: the template is set to m/d/yy but the file is yyyy-mm-dd, or month and day are swapped. Allocadia reads the year segment from the wrong position and lands outside the range.

A less common cause: an upstream system (ERP, accounting tool, procurement platform) sometimes exports a placeholder date such as year 9999, 3000, or 0000 to mean "indefinite" or "no end date." Those placeholders are also rejected on import.

How to fix it

1. Identify the failing row and column. They're both in the error message — the column name tells you the field that failed, the row number tells you where to look. ![SCREENSHOT NEEDED: example error message highlighting column and row]
2. Open the source file (CSV, in Excel or your editor of choice), jump to the row, and look at the value in the named column.
3. Inspect the value. You'll see one of two cases:
   • The value is genuinely out of range (e.g. year 3020 or 9999). Correct it to the intended date, save the file, and re-drop it at the import location (typically your SFTP folder). The next scheduled run will pick it up. If you need the import to retry sooner, contact Support to trigger it manually.
   • The value looks correct in your spreadsheet (e.g. 2030-08-09) but the import still fails. This points to a format mismatch between the file and the import template — see the next section.

Tip — scan the rest of the column. If one out-of-range date appeared, there may be others that didn't trigger the error this run (because they happened to fall inside the range by coincidence). A quick scan of the column for unusual leading digits — especially 9999, 3000, or single-digit-off years — before you re-submit will save another failed run.

If your file looks correct but the error keeps coming back

If the value in row N looks fine in your spreadsheet and you've confirmed the year is in range, it's almost always a date-format mismatch between the file and the import template configuration. This isn't something you can fix from the file itself. Contact Support with the file attached and we'll review the import template's column parse format together — it's usually a one-line adjustment.

Related articles

• How to map POs and Actuals on the Home page
• Importing POs and Actuals via SFTP into Allocadia
• What date range does Allocadia accept on imports?
• Why don't my POs and Actuals show up on new fiscal-year hierarchies in Allocadia?