My guess would be duplicate lines that were ignored / not counted more than once. That's odd for an invoice import though, but if these are updates and you included line key, that could explain it.

I've verified there aren't any duplicate lines.  We are using the same ItemCode for 2 of the lines on the invoice, namely "*TIME".  As a side note, could you tell me what prependig the * to the ItemCode does? We've been using that method when it's not an actual item in inventory.

Here's more detail info on the line that did not pass.

The left side is the header. The middle is the first line (which was not passed & ignored). The right side is another line from the invoice that did pass and was imported. (i've blanked out some sensitive info)

It shouldn't but line 326 could be updating line 325's detail record instead of adding a detail record. I've seen odd things like that before.
(* items are special "non-inventory" items, correct).

It shouldn't but line 326 could be updating line 325's detail record instead of adding a detail record. I've seen odd things like that before.
(* items are special "non-inventory" items, correct).

I'm curious about the "L.LotSerialFullyDistributed"=Y parameter. Could you explain (or point me to documentation) what this flag does?

More info on this. We've found that moving the line that is skipped to a different position in the import file (usually down a few lines in the invoice) will cause everything to work w/o skipping any lines. We, however, cannot determine what is causing this! Any ideas what would cause this?

Update: This problem seems to occur when two lines that are very similar are next to each other in the import, namely the Item Code and Item Type are the same on the two lines.  I still don't understand why the line gets skipped, especially since moving it to a different position fixes the problem.

L.LotSerialFullyDistributed pertains to items with the Lot or Serial valuation. (There is no documentation for things like this, outside of the help files).

What you describe sounds exactly as I suspected. The subsequent line is updating the previous row instead of adding a new one. I don't know what to suggest other than playing with the job settings to see if you can get something to work. Something odd like L.LineKey set to column 100 (i.e. something not in your data source) might do the trick.