Invoice header fields that disagree: INVOICE_FIELD_INCONSISTENT and multiple client IDs
A LEDES 1998B file is flat: one line per fee or expense, and no separate header row for the invoice. So every line repeats its invoice's own fields (the invoice date, total, billing period, description) alongside its own line item fields. What makes a group of lines one invoice is that they share an INVOICE_NUMBER. These two checks look at what happens when lines with the same invoice number don't agree about the rest.
INVOICE_FIELD_INCONSISTENT (error): one of the invoice-level fields has more than one value across the invoice's lines.
invoice 96542: INVOICE_TOTAL disagrees across its line items: ['1650.00', '2310.50']
The fields compared are INVOICE_DATE, INVOICE_TOTAL, BILLING_START_DATE, BILLING_END_DATE, and INVOICE_DESCRIPTION. Each field that disagrees is reported once per invoice, listing every distinct value found, so one bad invoice can produce several of these.
INVOICE_MULTIPLE_CLIENT_IDS (warning): one invoice's lines name more than one CLIENT_ID.
invoice 96542: its line items name more than one CLIENT_ID (00711, 00712) — an invoice normally bills one client, and 00711 (the first) is the one it's routed to
Why one is an error and the other a warning
The 1998B spec says that for each invoice number only the first value of an invoice-level field is valid. A system that follows the spec takes the first line's value and ignores the rest. So if line 1 says the total is 1,650.00 and line 12 says 2,310.50, the file isn't ambiguous to that system, just silently wrong: whatever the later lines meant to say is discarded.
CLIENT_ID is different. The spec ties it to the matter (LAW_FIRM_MATTER_ID), not the invoice, and one invoice may bill several matters. Two client IDs on one invoice isn't a spec violation, which is why it's a warning. It is almost always a mistake, though, since the client ID is what routes the bill, and only the first one gets used.
The usual cause: two invoices, one number
When several fields disagree at once (date, total, and period together), the lines almost certainly belong to two different invoices that ended up with the same INVOICE_NUMBER. Two exports concatenated into one file, a number sequence that reset, or a hand-built file reusing a number are the common paths. The tell is that the lines split cleanly into two groups, each consistent with itself.
Other causes, when only one field disagrees:
INVOICE_TOTALalone: the invoice was edited (a line added or written down) and the total was updated on some lines but not all. Check it against the line totals too; BriefCheck's invoice balance check compares the stated total with the sum of the line items.INVOICE_DESCRIPTIONalone: a free-text description typed per line rather than set once per invoice. Harmless in intent, but only the first one is kept.- The billing period alone: usually the same edit-after-export problem. It matters more than it looks, because BriefCheck's billing period checks read the period from the invoice's first line.
What to do about it
If the lines split into two self-consistent groups, give one group its own invoice number. That's the real fix; making the fields agree would merge two invoices into one wrong one.
If it's a single stale field, correct it on every line to the value that's actually true, which isn't necessarily the first one. Then fix whatever produced the file, since an export that writes a header field per line can write it inconsistently again.
For multiple client IDs, check the matters: if the invoice really covers matters for two clients, it should be two invoices.
Try it
Tier 2 (consistency), part of a Day Pass or Ledger subscription. These are BriefCheck's own checks rather than the underlying parser's, so there's no pre-built sample behind the account page's lookup for them yet. Changing INVOICE_DATE on one line of a multi-line invoice in a test file will trigger INVOICE_FIELD_INCONSISTENT directly.