>>If the information is valuable, set up an import process with a human clearing point.
>
>Thanks, this is exactly the plan. As Excel files are already being used, we can only rely on a cleaning (adjusment) phase, just before importing the data.

No idea what the process of creating the sheets in your specific case involves.
We had a specific case where first Big Iron dumps were read, imported to excel, then edited<6Backspace> mishandled.
For large imports/edit needs we imported the tables, generated simplisitic edit forms (we demonstrated a table wtih browse REdit, then created "real" forms via fwk) consisting of a Grid and a single record edit option with only record buffering.

Minimized errors like missing zeroes a lot, still allowed CtrlC CtrlV field editing - we also had a dummy memo field with drag&drop to import from other documents/pdf/Html screens first and then to manual field filling within the "app". We failed when trying to work off normalized data model and when trying to allow multi-field updates (Excel ranges Word Paragraphs or lists, CSV lines as sources). It worked when demoed, but when doing actual work often one person found a way to mark datasources in a way screwing up entry. Only KISS worked.

For the other cases: Build 2 teams:
1 dev to filter via automatics/program,
1 or more dataentry person for eyeballing

compensation should be at least correlated partially with the count of corrections, not only H spent.

that way you can keep customers for YEARS, saving customers quite a bit of cash while earning part of that
thomas