I had the same problem, my remote users were in the wilderness counting fish and measuring habitat. They took an Access app with local tables out there, collected the data, and then handed them off to me.
I was lucky to be using SQL Server (way too much data for Access) so I could build, save, and automatically run SQL Server Integration Services (SSIS) packages to import the data from Access. SSIS knows how to deal with Access DB's, and bunches of other structured storage.
That said, here are some non-SQL Server specific things I did that helped.
Batches: I made a batch table to keep track of which records were imported when. That way, if an import went wrong, I could easily delete only the records from that batch, and re-do the import. Just a simple table with an ID, LongDateTime, and whatever other mundane data that is helpful for your app (maybe record type, that sort of thing). Either relate it through an intermediate table (better IMO) or add a BatchID column to your destination table(s).
My data belonged to different entities, and they literally did own the data, so it was necessary to modify the SQL Server data structure to reflect that. There are other reasons that might dictate that your remote schema are different than their destination schema.
Data Cleaning: My end users were fish biologists, and habitat scientists, so they wanted to inspect and tweak their raw data and were qualified to do that. I gave them SQL Server Views that they linked to in Access which they were familiar with using. That's just one way, you could clean the data before import, write Stored Procedures and Views, or probably a combination of all three. Obviously, if you don't have SQL Server, you could accomplish much the same thing with queries.
