Of course! Should it be? As a generality, I would say "No." However, as Bob pointed out, it really depends on the data, or perhaps more correctly the type of data. I usually try to use three categories: Fixed data, semi-fixed data, and dynamic data.
"Fixed data" I equate to data values that:
1. Will not change or very seldom change, and
2. Provides a lynchpin for Db returns (i.e., return values).
These I consider to be part of the Db schema construct, so if you change one of these values, you are in essence changing the Db design.
"Dynamic data" equates to raw data and many other, but not all, inputs.
"Semi-fixed data" is not so well defined. It concerns that area of data that can change, but may require control to ensure the correct functional performance of the Db or provides the correct operand (in the same sense as a constant in an algebraic equation.
So, within the process you describe, which type of data are these people dealing with. That might help you determine which should be under formal control.
With that said, frankly I don't think would/should be your responsibility to ensure the accuracy of the inputs and outputs of the stages in the process. Or more directly: No, it is not your concern (as the CM specialist).
Granted, someone should, as a general rule of good business practice, keep each stage of inputs until the outputs are verified. Using your description as an example, "When the data file arrives, Jill possibly should keep a safe copy of it, her other inputs, and her output to Jack, at least until Jack (the next person) verifies the data. Retaining these artifacts allows her to readdress her activities if there is a conflict downstream.
Jack then should do the same with his "cleaned up" work, and the cutter/paster/merger, and so on. But this is a product of the business process not a CM process. If errors are occurring from the process, it is up to the business manager to determine whether it is the process, the people, or the automated parts producing those errors. If it is the process AND IF the process is under configuration control, it is your concern to ensure that any process changes are conducted according to "Hoyle." If the problem is with one or more automated elements, then conducting changes to correct those elements, NOT the data, are your concern.
When you say a "...a developer then manually cleans it up...," what do you mean by "a developer"? Jill or Jack is not developing anything in this process. Maybe they were hired as a developer, but when they are performing this process, they are data entry "specialists." I think if you keep that mind, it may be more clear that their activities, inputs and outputs in this process are not your concern.