Way back in 2016, I wrote this post about hiring mercenaries as (small) units. I still think that a focus on units from squad to company-scale is appropriate for wilderness play in ACKS - at the low end, a beastman warband can be modeled as about five gangs, each the equal of a squad of mercenaries. In the middle, a village is ~5-6 warbands, each on average 30 strong, so a small platoon-scale battle or good-sized squad-scale battle. On the high end, a village is about one or two companies, so a confederation of villages is a small company-scale battle or large platoon-scale battle.
A simplification of that hiring process struck me recently, though. Tracking how long a particular unit has been in production is a lot of state, and rolling for each type of mercenary randomly each month will lead to swingy results, where sometimes there is a drought and sometimes there is an overabundance of mercenaries. This is reasonable and realistic, but if one of my goals is to make preparing an expedition quicker, and if downtime spent hiring mercs is somewhat abstracted, then this approach is less than ideal.
We can preserve the expected value and distribution of available mercenaries by changing the order of operations.
Available mercenaries per month by market class:
VI: 20% chance of one platoon (or 1 squad)
V: 60% chance of one platoon (or 3 squads)
IV: 1 platoon, with 25% chance of a second platoon (or 6 squads)
III: 3 platoons, with 20% chance of a fourth platoon
II: 1 company, 2 platoons
I: 6 companies
Mercenary unit type (1d20):
1-4: Light infantry
5-10: Archers or crossbows
11-12: Heavy infantry
14-16: Light cavalry
17: Horse archers
18: Heavy cavalry
19: Cataphract cavalry
20: Exotic (dwarves, elves, elephants, beastmen, or roll again if nothing springs to mind)
(This isn't perfect - it slightly underweights light infantry, light cavalry, and horse archers, and slightly overweights longbows and cataphracts. But it's a reasonable starting point that avoids using d%s)
Independent of the roll for type, 25% of mercenary units are veterans.
Not sure about hiring search cost yet. It probably isn't unreasonable to say that you're searching for all available mercenary types, so about 8 or 10 times the cost to search for a single type under the core rules. The standard "half in the first week, a quarter in the second week, and the last quarter in the third week" schedule for finding units still applies if you're using it with high-fidelity timekeeping instead of "in some market in the nebulous time between open-table adventures" (in which case the gp cost becomes the more limiting factor).
I think this approach might have a couple of nice properties.
Using this to generate available mercenaries is almost certainly faster than the core system. The number of rolls required, even in large markets, remains quite small, especially if you roll the d20 for type and the d4 for veterancy at the same time (if you have a couple of matched pairs of d20s and d4s, this parallelizes even better). Since mercenaries are found and hired as units, the reaction roll to hire rule might actually be used rather than ignored. Additionally, I like that there are no or almost no "dead rolls", where you're just rolling 0 mercs / unavailability of a type.
I think it would be easy to create culture-specific mercenary type tables; chaotic domains get their own table, dwarven settlements get their own table, desert settlements with camels and elephants, western european troop mix without cataphracts and horse archers, norse unit comp, etc. This is somewhat dangerous though, because the average value of those troops might be higher or lower than baseline, and then the economy gets a little out of wack. If you replace the 20th entry with an Exotic Mercenary Type subtable, and then customize that by culture, it could get even wilder.
I think this system would also help address one of the problems that we had in the early mid-levels in ACKS, where we would travel between settlements and pick up tiny piddling numbers of different types of mercenaries and not have enough of any one type to constitute a unit. This system always gives you a unit. It might not be a good unit, and it might not be the type that you wanted, but it moves the problem of assembling units up one layer (you might still need to build a platoon out of squads, but at least you don't have to build squads out of individuals), and combining squads into mixed platoons (of eg bows+longbows, light cav+horse archers, and heavy cav+cataphracts) or platoons into mixed companies may be easier when you're already starting with nice round unit numbers. If certain combinations in certain ratios are expected to occur often, it would even be easy to have those mixed-unit stats on hand.
There is probably room here for also randomly generating mercenary officers attached to / in charge of each unit. Might slow things down a lot though.
One weakness here is that this abstraction leaks - when it comes time for a hired mercenary unit to "heal" in town, replacing losses with fresh troops, the number of individual troops of a particular type matters. So we can't jettison the old tables entirely (but we might be able to reframe them as "healing rate of unit by type and market class", and then take averages rather than ever having to roll). But then you also don't want to have both healing and hiring in the same market in the same month. So that gets kind of gnarly.
In retrospect, rolling slingers into archers instead of into light infantry may have been a mistake, as archers come out really heavy in this table. But this is easy to correct here - changing light infantry to 1-6 and archers to 7-10 would get pretty close (or light infantry 1-4, slingers 5-6, archers 7-10, if I wanted to add slingers back). Likewise, maybe I should've split medium cav half-and-half between light and heavy instead of all into light. It's possible that there are other artifacts in total available troop numbers or the type distribution as a result of basing it on my previous work, which was already an approximation. So this might benefit from going back to the core numbers and starting over with this approach in mnd.
I wonder if a similar approach would work for magic items; currently I have a script to roll the number available for each magic item, which results in scrolls being really quite common.