If a friend asked me for that advice, I would begin with the software listed for both occupations and ask which programs they already know. Then I would look at the accountants' remaining examples alongside job postings. That gives me a set of programs to ask about, without treating every entry as a course to take.
I looked through the software examples in release 30.3 of O*NET, a public database of occupation descriptions, to see how far I could take those comparisons. I compared pairs of jobs and checked how much the results depend on the length of each list. Some occupations have hundreds of examples. Others have one.
What is on the list
The lists contain examples that O*NET attaches to an occupation, rather than measurements of which programs workers open each day. A missing example does not mean nobody in the job uses it. I looked at 923 covered occupation codes. Some describe broad occupations and others describe specialties, so I am counting records here, not separate groups of workers. Excel is listed for 859 of them, or 93.1%. Word is on 84.9% and Outlook on 69.6%.
Excel is listed for 93% of covered occupation codes
The eight most widely listed software examples among 923 occupation codes in O*NET 30.3. Each bar track spans 0% to 100%.
Across those codes there are 8,753 distinct example names, and 6,139 of them show up in only one code. I kept every name exactly as spelled. Versions and aliases are still separate, and a software suite can appear alongside its individual programs. The counts therefore describe names in the database, rather than a verified list of distinct products.
Rare names and long lists
I wanted to know which occupations have unusual software, so I scored each one by how rare its listed names are. A name found in fewer occupations counts for more. Excel contributes little because it appears in nearly every list. A name found in a single code contributes much more, even though that program may be no harder to learn or more valuable than the rest.
Lists run from 1 name to 430, and longer lists tend to score as rarer, with a rank correlation of 0.55. In my activity analysis the pattern ran the other way. That association makes it hard to separate unusual software from differences in how thoroughly the lists were documented.
Occupations with longer software lists score as rarer
Median rarity score by number of listed examples, 923 occupation codes. Each bar track spans 0 to 5.
Three occupations tie for the top score. Reinforcing Iron and Rebar Workers have four listed names, Roof Bolters in Mining have two, and Musical Instrument Repairers and Tuners have ten. Every name on those lists appears in just one covered code. All three occupations are equally distant from every other occupation under this comparison, so choosing one "closest" neighbor would hide a 922-way tie.
Comparing two jobs
For the bookkeeping-to-accounting question, I would compare the two lists directly. I count the names they share, divide by the longer list, and subtract that fraction from one. The distance is zero for identical lists and one when nothing is shared. Accountants and Auditors list 237 names and bookkeeping clerks list 118. They share 88, so the distance is 0.63. Software Developers and Software Quality Assurance Analysts and Testers have lists of 430 and 429 names, with 379 shared, a distance of 0.12.
To understand why two lists differ, I borrowed an idea from ecology. Ecologists comparing species at two sites distinguish different species from one site's species being mostly contained in the other. Applied to software lists, those components are called replacement and nestedness. Replacement means different names on the two lists. Nestedness depends on shared names as well as list sizes, so it is more specific than a difference in length. Neither describes programs being replaced over time.
About 75% of the bookkeeping clerks' list also appears for accountants. Its dissimilarity splits about evenly between the two components. The designers' lists differ mostly in which names appear. Only about half of the industrial designers' names appear for graphic designers.
Different examples explain most of the gap between the designers' lists
Four selected occupation pairs, O*NET 30.3. Replacement and nestedness add to the Sorensen total, subject to rounding. Scroll sideways on small screens to see all columns.
| Pair | List sizes | Shared | Shorter list shared (%) | Replacement | Nestedness | Sorensen total |
|---|---|---|---|---|---|---|
| Accountants and Auditors, Bookkeeping Clerks | 237 / 118 | 88 | 74.6% | 0.254 | 0.250 | 0.504 |
| Software Developers, Quality Assurance Testers | 430 / 429 | 379 | 88.3% | 0.117 | 0.001 | 0.118 |
| Industrial Designers, Graphic Designers | 61 / 79 | 30 | 49.2% | 0.508 | 0.063 | 0.571 |
| Registered Nurses, Licensed Practical Nurses | 43 / 26 | 18 | 69.2% | 0.308 | 0.171 | 0.478 |
I use this breakdown to inspect selected pairs, while keeping the original neighbor rankings. It gives me no estimate of how easily a worker could move between jobs.
Grouping the names changes the comparison too. For this calculation I kept each name's recorded category attached, since the same name can have different categories across occupations. Grouping those name-and-category labels into 134 categories retains about 43% of their information about occupation identity. Grouping into 17 broader families retains about 19%. These percentages describe recorded labels, with each occupation counted equally. They do not measure economic value.
Software, activities, and skills point to different neighbors
I also asked whether the occupations closest in software are the same ones closest in work activities or skills. Of the 923 covered codes, 894 have complete skills profiles. Removing 71 codes with suppression flags leaves 823 for this comparison. Accountants and Auditors and Software Developers are excluded, so these results do not extend to those earlier examples.
I compared the five nearest neighbors, keeping ties at the cutoff. For 55.8% of occupations, the activity neighbors and the software neighbors have nothing in common. The median overlap is zero. It is also zero between software and each of the four skills blocks. Essential and Transferable skills stay separate, as do their Importance and Level ratings. Ties matter here, since 515 of the 823 software queries end up with more than five neighbors.
Commercial and Industrial Designers have Fashion Designers as their closest activity neighbor and Graphic Designers as their closest software neighbor. Essential skill levels instead point to Landscape Architects. Registered Nurses have two tied activity neighbors, Acute Care Nurses and General Internal Medicine Physicians. Their closest software neighbor is Patient Representatives.
For a training question, a software match gives me programs to ask about. Activities and skills give me other differences to investigate before suggesting a move. The disagreement does not tell me which comparison is better, and it depends on the distance rules as well as the data.
Even within skills, I would be cautious about one closest match. Switching from average ratings to percentile ranks leaves about 48 to 55% of occupations with no shared nearest neighbor between the two methods. At five neighbors, fewer than 1% have no shared neighbor, although the sets still change. The broad distance ordering is more stable than the top match, so I would show several nearby occupations and their skill gaps. The inputs are average analyst ratings, so none of this tells me how many workers have a given skill level. This check tests a measurement choice, rather than sampling uncertainty.
Does employment change the picture?
A training provider deciding how many places to offer might also want larger occupations to count more. I used onet2r to pair the activity data with May 2025 national employment estimates from the Bureau of Labor Statistics' Occupational Employment and Wage Statistics (OEWS) program. I used one broad O*NET description per official occupation code, without also counting its specialties, and kept only published employment cells with all those descriptions available. That left 765 descriptions in 756 cells, covering 146,251,550 jobs, or 94.1% of the official total.
For combined cells, I split employment equally among their constituent descriptions. That is an assumption, since the published cell does not provide that breakdown. On this matched set, equal-description and employment-weighted activity prevalence have a rank correlation of about 0.66. "Order materials, supplies, or equipment" goes from 8.76% of descriptions to 17.90% of allocated employment, and "Calculate costs of goods or services" goes from 3.27% to 13.26%.
I also let each complete cell's employment fall anywhere among its constituent descriptions. For 92.4% of the 2,034 linked activities, the resulting lower and upper bounds are identical. Their prevalence does not depend on how I split those cells. The missing profiles remain unresolved, and I have not included OEWS sampling error. OEWS also excludes the self-employed and the military. A separate 13,890-job difference between the official total and the returned detailed cells remains unexplained and unallocated.
The weights estimate employment attached to mapped descriptions. They cannot tell me how long people spend on an activity or which software they use. An estimate of AI's effects would need evidence beyond these links.
What I would do with this
For my friend, I would turn the comparison into questions for someone doing the accounting job they want. Which of the listed programs does that person actually use? Which would they expect a new hire to know? A program listed only for accountants would be worth asking about, but its absence from the bookkeeping list would not tell me whether my friend already knows it.
Excel is listed for both jobs, so knowing that alone does little to choose a course. I would want to know what the accounting role asks someone to do with it, then compare that with what my friend can already do. O*NET helps me prepare for that conversation. I would still need the conversation before recommending training.
Read and reproduce the analysis
The software article has the formulas and every table. The activity, employment, and skills article covers the rest. Both build from bundled tables, which sit in the onet2r repository at the pinned commit. I did not combine these domains into a single score, and education and experience composites are not part of this analysis.
Data attribution
This post uses modified information from the O*NET 30.3 Database, US Department of Labor, Employment and Training Administration (USDOL/ETA), under CC BY 4.0. The public archive was used to calculate software list overlap, activity prevalence, skills distances, and information retained under grouping. Employment estimates come from the Bureau of Labor Statistics' May 2025 national OEWS release. USDOL/ETA has not approved, endorsed, or tested these modifications. O*NET is a trademark of USDOL/ETA.