Revisions are common and expected due to the nature of how BLS collects employment data through surveys of workplaces. BLS has a great article from 2013 that ex

Revisions are common and expected due to the nature of how BLS collects employment data through surveys of workplaces. BLS has a great article from 2013 that explains this[0] if you're interested. The gist: > In the survey sample, businesses report the total number of people who worked or received pay during the pay period that includes the 12th of the month. Although BLS uses a variety of methods to gather these reports as quickly as possible, many businesses do not have their payroll data ready to report by the scheduled date that BLS initially releases the data. In 2012, for example, the average collection rate at the time of the initial release was 73.1 percent. Most of the time, the initial estimates are sufficient for analyzing labor market trends. Later revisions offer greater accuracy of the period. Most of the time, though, the revisions don't significantly alter our understanding of the period. Sometimes, however, they do: > So why doesn’t BLS wait until it has all the reports to make the estimate and avoid revisions? Users of the data are intensely interested in the earliest possible read on labor market developments, and experience suggests that the initial estimate is generally very good. For example, in 2012, the average monthly employment change using the first estimate would have been +142,000, compared with a monthly average change of +165,000 using the third estimate. (See table 1.) Nevertheless, it is true that in some months, revisions are large enough that they change the users’ perspectives on the current state of the economy. In November 2012, for example, the initial estimate of over-the-month change was +146,000, while the third estimate was +247,000. As for manipulating the data, it's pretty unlikely. BLS goes to extraordinary lengths to maintain data integrity[1][2] because they're quite aware of the consequences to global markets if they tried to fudge data. Hell, simply leaking the report a few hours early would cause problems. For that matter, it's not the sort of data you're going to get away with manipulating for very long. There's lots of other data economists monitor that broadly track with unemployment data (not to mention the alternative labor underutilization rates[3] reported by BLS). Trying to manipulate the official U-6 rate means having to fiddle with the alternatives as well, only for some analyst or economist to come along and go "huh, that's weird." Maybe that "huh?" moment amounts to nothing at all. Or maybe it opens the door to what might end up being a career-shaping paper for the economist. Or serious gains or losses for the analysts' firm. The kind of data incongruities you'd inevitably get are basically catnip for both analysts and economists alike. Plus, they're monthly numbers. You'd have to continue the deception for months on end to avoid creating a weird spike that will definitely garner attention, all while somehow figuring out a way to massage the numbers back to reality when you're done doing whatever it was you were doing. You can't just go back to reality for the next report, and the longer it continues, the more likely it is you'll get caught. It's a hell of a task, and you're going to somehow have to manage it in an incredibly short amount of time, issue the expected revisions without giving it away, and then do it all over again the next month. With each falsified report, your task gets harder. 0. https://www.bls.gov/opub/btn/volume-2/revisions-to-jobs-numbers.htm https://www.bls.gov/opub/btn/volume-2/revisions-to-jobs-numb... 1. https://www.bls.gov/bls/data_integrity.htm https://www.bls.gov/bls/data_integrity.htm 2. https://www.nytimes.com/2020/06/08/business/economy/jobs-report-data.html https://www.nytimes.com/2020/06/08/business/economy/jobs-rep... 3. https://www.bls.gov/news.release/empsit.t15.htm https://www.bls.gov/news.release/empsit.t15.htm