Short answer : yes you can (and should ...) - but you should also read further
Medium answer : you should not sync by letting any value enter into your database without being controlled, but for example keep a trace of last synced data per distributor and reject any older data unless explicitely established as corrective - but you should still read further
Long answer : the answer will be technical, and as the programmer it will be your responsability. But the problem is on business layer : what do you want to prevent ? A mistake of a distributor sending again an old file, or something totally different ? An intentional attempt from a distributor to put wrong data in your base ? An external attack (from a concurrent, a script kiddy, or an abandonned girl friend ...) deliberately sending forged data to destroy your database ? And who is accountable for the incoming data ? Do you keep traces of who (and how identified) sent any data ? And what is the risk (occurence and damage) of corruption of data ? How much can you (or your company) invest in protective counter mesures ? You must be able to answer to the question what should be done, why, and what is the risk if not done before considering the how.
And if the risk of synchronizing wrong data is too high, you could even considere the possibility that your distributors directly use a web application on a unique (centralized) database.
If you have allready the answer to business level questions, and you know that you really need to protect your database against a distributor adding old sales invoice, you have two ways :
- you receive an export of distributor data : simply check that each invoice is correct before copying it to your database
- you receive an offline dump, or use true database synchronization methods : do not synchronize on your real database but on a copy per distributor, and put controls between that copy and your real base.
You can have one single copy if your process can ensure that only one distributor at a time can synchronize its base.