Autonumber() itself couldn't be reversed. If you need the origin values you need to load them, too. By a single field as the source for the autonumber() it has no much benefits to apply it because you will just add an extra field to your datamodel (it could avoid calculations over the key-fields but at the moment I don't remember a usecase in which it would cause really trouble).
If there are multiple fields combined in an autonumber() it will have benefits even if you keep all of them within the datamodel. Essentially for this behaviour is the fact that the fields (system-tables) only store distinct values and reference with a binary pointer to the data-tables - unless the autonumber() because field-value and pointer-value are the same and therefore an autonumber() didn't need to be stored.
Quite important is that autonumber() is aimed as a performance-feature within a final application. In the ETL in beforehand it's rather seldom useful because you need to ensure that you would always control the load-order of these field(s) over all related tables. Surely there will be usecases in which it may work but trying to implement it means to add another level of complexity in the ETL workflow.