Tip #72 Scopus Export Inconsistency Workaround
Featuring guest author, information specialist, and Scopus mechanic Dr. Marc von Gernler, University of Bern.
[Dr. von Gernler devised a brilliant work around for when Scopus exports fewer records than are in a results set. At the end of his post are details of Elsevier HelpDesk experiences from Database Tips Blog editor Michele McGinnis related to this issue.]
The crux: Scopus export discrepancy between number or records retrieved and exported is an inconsistently experienced issue. If you happen to experience this issue, this workaround will identify the missing records and save your systematic review! It may have been resolved in May 2026 with Scopus export performance fixes, but it's not clear that it was.
Introduction
At a certain point in a systematic literature search, when all search strategies have been developed, the final search is at hand. A moment the review team is yearning for. In this final search, each database is searched and all the results are exported for the screening process. However, this export sometimes proves to be one last challenge for the searcher.
Background
In the past year there have been incidents of export problems in Scopus where the number of results retrieved did not match the number in the exported file. In each case, the number exported was fewer than the number of records retrieved. For instance, the Scopus search interface shows a result of 2676 records, whereas the exported RIS file contains 2538 references. With numbers this high it is virtually impossible to find out quickly which 86 records are missing in the exported set, let alone how to export them. That's where this workaround might help, should you find yourself in the same situation.
Because it is not possible to replicate the issue on demand and for ease of illustration, we'll use a simple search of the author's name, which results in 15 records. We'll pretend that when we exported records, only 11 of them exported.
Workaround
First of all, we need to remove the already exported records from the search results in Scopus leaving only those records that were not exported. In most databases, records possess one unique identifier. In Scopus, this is the so-called EID, which looks like "2-s2.0-105028324613". Unfortunately, even if you check the box for EID as an export option, it is not included in the RIS file. So we have to export the results again using the CSV option. Once we have the EIDs, we create a searchable string to remove the already exported records from our search.
 |
| Workaround visualization for a search that resulted in 10 records and an export of 7 |
Here are the step-by-step instructions:
1. Export the available results again as a CSV. Make sure the EID is selected as a data field. It appears that all 15 records will export, but only 11 will.
 |
| EID export option |
3. Copy all the EIDs into an empty text document. The next steps depend on what kind of software you have available.
a) For Word using Find/Replace option: paste as plain text then find and replace `^p` with ` OR ` (make sure you enter a space before and after OR) . This should replace all paragraph breaks with the Boolean Operator "OR". There may be a dangling OR at the end of your string, you'll want to delete it.
b) In case you are comfortable using a text editor, which is able to search and replace Regular Expressions, (such as Notepad++): Search and replace `\r\n` with ` OR `. This should replace all line breaks and carriage returns with the Boolean Operator "OR".
4. You should now have all EIDs in one line with "OR" in between them. Add `EID (` at the beginning and close with `)` at the end of the line.
5. At the end of your search string in Scopus, remove the EIDs from the search by adding `AND NOT EID (2-s2.0-...)`.
 |
| Original search removing previously exported records |
Browser Cache Issues
Unfortunately, browser caching may complicate the workaround. Our testing found that when we deployed the search more than once, subsequent record counts matched the number of exported records and not the number of records retrieved the first time. To avoid this, once you discover a discrepancy between retrieved and exported records, export the EIDs to CSV before redeploying the search for any reason. Otherwise, you may have to clear browsing history or log out and back in.
Regional Issues with CSV Files
Opening a CSV directly with Excel can be problematic due to regional settings, which may prevent separate columns from being recognized and cause all data to merge into the first column. For example, in German-speaking regions Excel expects a semicolon s the separator by default, whereas in the United States the preset separator is a comma. This AI-generated visualization provides solutions.
Conclusion
Until the cause of the incomplete export has been found and fixed, or in case the problem emerges again, this workaround should help both time and nerves at a critical stage of your systematic literature search. This workaround might be also applied to similar databases, in which the documents can be searched using their unique identifier.
Timeline of Elsevier HelpDesk interaction from Michele
I first experienced this issue in October 2025 while performing searches for a scoping review. After several weeks with no resolution the research team opted not have Scopus as part of its information sources. In two subsequent reviews, we included Scopus results with a caveat describing the export discrepancy in the methods. Marc's workaround is truly a review saver. The following is a history of my interactions with Scopus on this matter.
October 22, 2025 Scopus search for scoping review resulted in 3442 records but the number of records exported from the RIS file to EndNote was 3328. Missing in the export were 114 records. I opened a ticket with the Elsevier Helpdesk.
October 25, 2025 I received a response asking me to "provide the search string, preferred file type and a full-page screenshot including the website URL of the issue you are currently experiencing."
October 31, 2025 I am instructed to clear my browser cache and cookies. I had already done this along with cleared browsing history, switched browsers, and had colleagues test the search on their computers.
November 03, 2025 My ticket was escalated to the Scopus Second Line Support team.
November 12, 2025 I requested an update and asked if this was a widespread issue.
November 17, 2025 I was told this "widespread" issue was still being investigated. I was provided with two EndNote files to see if the correct number of files for my search would export.
November 20,2025 I tested the files and they were off by 13 records, which I attributed to the 3-day delay where records were likely added to Scopus. So, the export appeared to be resolved.
November 21, 2025 A colleague saw my post about this on Expert Searching list and asked if there was a workaround. I was not aware of one.
February 26, 2026 The Elsevier HelpDesk person who had been assisting me reached out to ask me to try running and exporting the search again and suggested that if a discrepancy persists, it could be due to the frequent use of the PRE/0 proximity operator. They stated "While the syntax is valid, it is computationally heavy and not recommended—particularly in large or complex combined queries—as it may affect performance or output consistency." They offered to help me simplify the query to improve readability. I accepted the offer.
May 14, 2026 And this today from the Customer Experience Champion, "To clarify, Scopus does not enforce a strict limit on the number of Boolean or proximity operators in a query. However, when searches become highly complex—particularly with multiple proximity operators, nested logic, and exclusions combined (i.e., Exclude or Limit-to)—the system may require additional processing during certain operations such as exporting results. This can occasionally lead to inconsistencies, even when the search itself runs successfully." This was not the technical explanation I was seeking, but rather a restatement of the issue many librarians have been experiencing.
Along with this reply, I received the long anticipated simplification of my query. Not only was the query simplified, but it resulted in nearly 3000 fewer records.
In its May 2026 Nightingale release (2026 Scopus product release notes are named after birds), Scopus indicates export performance bugs were fixed, but I don't know if this includes the export discrepancy.
https://service.elsevier.com/app/answers/detail/a_id/39488/supporthub/scopus/kw/
Comments
Post a Comment