Scaling a sequential program into chain of queues
It looks like you can do the following:

Assigner 

Reads from the assigner queue and assigns the proper ids
Packs the data in bulks and uploads them to S3.
Sends the path to S3  to the Dumper queue

Dumper reads the bulks and dumps them to DB in bulks
I am trying to scale an export system that works in the following steps:

Fetch a large number of records from a MySQL database. Each record is a person with an address and a product they want.
Make an external API call to verify address information for each of them.
Make an internal API call to get store and price information about the product on each record.
Assign identifiers to each record in a specific format, which is different for each export.
Dump all the data into a file, zip it and email it.

As of now all of this happens in one monolithic python script which is starting to show its age. As the number of records being exported at a time has grown by about 10x, the script takes a lot of memory and whole export process is slow because all the steps are blocking and sequential.
In order to speed up the process and make it scalable I want to distribute the work into a chain of SQS queues. This is quite straightforward for the first 4 steps:

Selector queue - takes a request, decides which records will be exported. Creates a msg for each of them in the verifier queue with export_id and record_id.
Verifier queue - takes the id of the record, makes the API call to verify its address. Creates a msg in the price queue with export_id and record_id.
Price queue - takes the id of a record, makes the API call to get prices and attaches it to the record. Creates a msg in the assigner queue with export_id and record_id.
Assigner queue - takes the id of a record, assigns it the sequential export ID. Creates a msg in the dumper queue with export_id and record_id.
Dumper queue - ???

This is all fine and dandy till now. Work is parallelized and we can add more workers to whichever step needs them the most. 
I'm stumped by how to add the last step in the process?
Till now all the queues have been (suitably) dumb. They get a msg, perform an action and pass it on. In the current script, by the time we reach the last step, the program can be certain that all previous steps are complete for all the records and it is time to dump the information. How should I replicate this in the distributed case?
Here are the options I could think of:

The dumper queue just saves it's incoming msgs in a DB table till it gets a msg flagged "FINAL" and then it dumps all msgs of that export_id. This makes the final msg a single point of failure. If multiple exports are being processed at the same time, order of msgs is not guaranteed so deciding which msg is final is prone to failure.
Pass an expected_total and count in each step and the dumper queue waits till it gets enough msgs. This would cause the dumper queue to get blocked and other exports will have to wait till all msgs of a previously started export are received. Will also have to deal with possibly infinite wait time in some way if msgs get lost.

None of the above options seem good enough. What other options do I have?
At a high level, consistency is more important than availability in this problem. So the exported files can arrive late, but they should be correct.
Msg Delay Reasons
As asked in the comments:

Internal/External API response times may vary. Hard to quantify.
If multiple exports are being processed at the same time, msgs from one export may get lagged behind or be received in a mixed sequence in queues down the line.