Picture the start of a benchmarking week. A supplier sends a new datasheet as a PDF. A teardown report arrives with its tables. A competitor’s web page holds the one number that matters. Each source has to be read, and each value has to be placed in the right field before anyone can compare anything.
A benchmarking platform is only as good as the data inside it, and that data starts as documents and images. The step looks like administration. In practice it decides how quickly a new model can be benchmarked and how far the comparison can be trusted.
So does it still make sense to build benchmarking data by hand? The research below shows where the hours and the errors go, and the last section ends with a test you can run on your next batch of documents.
Where the Hours Go
Data work rarely appears as a line in a project plan, yet it takes time. In a 2013 Harvard Business Review article, data quality expert Thomas Redman wrote that studies show knowledge workers waste up to 50% of time hunting for data, identifying and correcting errors, and seeking confirmatory sources for data they do not trust. The article does not name those studies, so read the figure as an order of magnitude.
Engineering teams report a similar pattern. In research covering nearly 250 manufacturers, Tech-Clarity found that engineers spend 32% of their time on non-value added work, with manual data management tasks accounting for the majority of it.
Quality is the other half. A 2020 study in Business Horizons analysed 75 data quality assessments and found that on average 47% of recently created data records had at least one critical error, and only 3% of data quality scores were rated acceptable. At national scale, Redman, citing IBM, put the yearly cost of poor-quality data in the US at 3.1 trillion dollars in 2016. None of these studies is about benchmarking specifically, but anyone who maintains a benchmarking database will recognise the pattern.
Where the Errors Enter
Entry errors are well documented, and they are not rare. In a 2000 review of spreadsheet research, Raymond Panko reports that field audits of 54 spreadsheets from 1997 onward found errors in 91% of them, and that laboratory experiments in which 998 participants built 1,170 spreadsheets found errors in 51%.
Checking by eye does not close the gap. In a randomised experiment, Barchard and Pace assigned 195 students to enter data by single entry, visual checking or double entry. Visual checking produced 2,958% more errors than double entry, roughly thirty times as many, and was not significantly better than single entry.
The errors that matter most are the ones that need interpretation. A study of a clinical data repository, published in BMJ Open, found an error rate of 5.2% in fields that required interpretation, against 1.3% in fields that could be transcribed directly. It covers medical data, not benchmarking, but the lesson carries over: the hard part of entering data is deciding what each value means.
From Documents to Data
DocuFlow, the AI layer inside GOBENCH, turns documents into data. Drop in a PDF or a URL and DocuFlow reads the text, tables and images, and suggests where each value belongs.
Reading a document well is a technical problem in its own right. IBM Research’s open-source Docling converts PDFs with AI models for layout analysis and table structure recognition, and a March 2026 benchmark of 21 PDF parsers on 451 tables found significant performance disparities between them. Neither paper is about DocuFlow. The second one shows that extraction quality varies between tools, so an extracted table remains a suggestion until it has been checked.
Photos and teardowns follow the same logic. One photo becomes a clean cutout. One teardown becomes every component, separated and grouped. The scale explains why: A2MAC1’s vehicle data goes down to 2,500 components per car, and an April 2026 article on the CTI Symposium site notes that teardown databases today contain thousands of components, materials and manufacturing processes.
DocuFlow’s AI then checks every value and flags mismatches instantly, so the team does not lose time chasing errors. Human review has its own limits, and they are worth knowing. In a randomised experiment with 2,784 participants reviewing AI-generated pre-annotations of emissions data from corporate reports, Beck and colleagues found that reviewers corrected about 82% of spelling and digit errors, but only about 31% of the errors that required knowledge of the annotation rules.
Does It Still Make Sense?
The research points to three costs of the manual route. The first is time: about a third of engineering time, 32%, goes to non-value added work, and manual data management is most of it. The second is errors: checking by eye does not catch what double entry catches. The third is judgment: the errors that need knowledge were the ones reviewers corrected least in the experiment above. A platform that reads the document, suggests where each value belongs and flags mismatches can give time back at each of these points. What took days now takes minutes, as the DocuFlow video puts it, and that time returns to the knowledge and experience of the engineers.
Try It on Your Next Batch
Take the last batch of documents your team entered by hand and run a simple test.
- Count the hours it took, and count the corrections made afterwards.
- Drop the next batch into DocuFlow as PDFs or URLs, and review the suggested placements and the flagged mismatches.
- Compare both counts, hours and corrections, and decide what the team does with the time it gets back.
Less time entering data. More time to apply your knowledge.
Sources
- Thomas C. Redman, Data’s Credibility Problem, Harvard Business Review, December 2013 (reposted on SAP Community).
- Michelle Boucher, How Are Engineers Spending Their Time?, Engineering.com, 12 April 2015, reporting Tech-Clarity’s research Reducing Non-Value Added Work in Engineering.
- Nagle, Redman and Sammon, Assessing data quality: A managerial call to action, Business Horizons, 63(3), 2020.
- Thomas C. Redman, Bad Data Costs the U.S. $3 Trillion Per Year, Harvard Business Review, 22 September 2016 (reposted on SAP Community).
- Raymond R. Panko, Spreadsheet Errors: What We Know. What We Think We Can Do, EuSpRIG Spreadsheet Risk Symposium, July 2000.
- Barchard and Pace, Preventing human error: The impact of data entry methods on data accuracy and statistical results, Computers in Human Behavior, 27(5), 2011 (abstract).
- Hong et al., Error rates in a clinical data repository: lessons from the transition to electronic data transfer, a descriptive study, BMJ Open, 2013.
- Auer et al., Docling Technical Report, IBM Research, arXiv:2408.09869.
- Horn and Keuper, Beyond String Matching: Semantic Evaluation of PDF Table Extraction, arXiv:2603.18652, March 2026.
- C Talk | A2MAC1: Cracking the Data Code of Automotive Transformation, Gasgoo, 28 May 2025.
- Ivan Jovanovic, Data Driven Cost Measure Generation for Automotive Systems Using Teardown Intelligence and AI, CTI Symposium, 14 April 2026.
- Beck, Eckman, Kern and Kreuter, Bias in the Loop: How Humans Evaluate AI-Generated Suggestions, Harvard Data Science Review, 8(2), April 2026.
