>I hate automation :-(

You are likely to get most problems, not from the technical stuff you mention, but from users saving data in different formats - e.g., what used to be in column C suddenly appears in column D, or data rows start two rows lower, because two more rows were inserted in the header.

Make a document describing the assumptions made for importing, e.g.:

Data will only be imported from the first spreadsheet of the file.

Column A contains the article code, column B the article description, column C is not used for the import, column D contains the quantity.

Data will be imported, starting from row 5. As soon as an empty cell is encountered in column A, the import stops - so don't insert blank lines between the data items.

Cell formatting, such as bold, font size, etc., don't affect the import; the user may freely use such formatting in the spreadsheet.

(etc.)

Have the users review it, see whether they agree - and if possible, sign it. Of course, it may be necessary to change the definition of the data format eventually, but it should be made clear that any such change will lead to additional work for the programmers, and possibly incompatibilities with documents from a previous format.

Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)