Line item dated outside the billing period: three LEDES date checks and what trips them
Every LEDES invoice carries three kinds of date: the billing period (BILLING_START_DATE to BILLING_END_DATE), the INVOICE_DATE, and a LINE_ITEM_DATE on each fee or expense. A format check only asks whether each one is a real date in YYYYMMDD form. It never compares them to each other, so a file can pass structure checks cleanly and still describe a timeline that doesn't add up. These three checks compare them.
LINE_ITEM_DATE_OUTSIDE_PERIOD: a line item is dated before the period starts or after it ends.
invoice 96542: line item 14 is dated 19981221, outside the billing period 19990101 to 19990131
BILLING_PERIOD_INVERTED: the period ends before it starts.
invoice 96542: billing period ends (19980101) before it starts (19990131)
INVOICE_DATE_BEFORE_PERIOD_END: the invoice is dated before the period it bills for has finished.
invoice 96542: invoice date (19990125) is before the billing period ends (19990131)
All three are checked per invoice, using that invoice's own period. The bounds are inclusive: work dated on the first or last day of the period is inside it, and an invoice dated on the period's last day is fine. A line item with no date, or an invoice with either end of its period blank, is skipped by the line item check rather than flagged; there's no period to compare against.
Why a line item lands outside the period
Late time. By far the usual cause. A timekeeper enters work from last month after last month's invoice already went out, and the billing system sweeps it into this month's invoice with its true date. The file is honest about when the work happened, which is exactly why it no longer fits the period the invoice claims to cover.
Expenses dated by the vendor, not the matter. A disbursement often carries the date on the vendor's own bill (a court reporter, an expert) rather than the date it was incurred for the matter, and the two can fall in different months.
A period set by template. Some exports stamp every invoice with the calendar month it was generated in, whatever the line items actually cover. If several line items are outside the period, and all on the same side of it, look at how the period is set before looking at the line items.
Why a period inverts
Almost always a swapped pair: start and end written into each other's columns by a custom export or a hand-edited file. The message shows both dates, and if they look like a sensible period read backwards, that's what happened. Less often, it's a year typo on one end (19980131 for 19990131), which reads as a period running a year backwards.
Why an invoice predates its own period
Pre-billing. An invoice generated on the 25th "for the month" with a period ending on the 31st. The invoice date is when it was produced, the period end is a promise about work not yet done, and the file states both.
The same swapped-column problem as above, this time between INVOICE_DATE and BILLING_END_DATE.
What to do about it
For late time, there are two honest fixes, and which one is right is the client's call, not the format's. Either bill the late entries on their own invoice whose period covers when the work was done, or widen this invoice's period to include them. Many clients' billing guidelines have a rule about how late time may be billed at all. Check those before resubmitting; see billing guidelines vs. the LEDES spec for why that rule lives in the guidelines and not in the file format.
For an inverted period or a predated invoice, fix the dates at their source (the export or the template), not in the file by hand, or the next invoice will carry the same mistake.
One thing to rule out first: these checks read the period from the invoice's first line. In a flat LEDES file every line repeats it, and they're supposed to agree. If they don't, BriefCheck also reports INVOICE_FIELD_INCONSISTENT for that invoice; fix that first, and see invoice header fields that disagree.
Try it
Tier 2 (consistency), part of a Day Pass or Ledger subscription. These checks are BriefCheck's own rather than the underlying parser's, so there's no pre-built sample behind the account page's lookup for them yet. A real (or test) file with one line item dated a day before BILLING_START_DATE will trigger LINE_ITEM_DATE_OUTSIDE_PERIOD directly.