Okay, so I think we can actually tease this matter out into two issues. First, there's the compliance question of whether the PCI requirements compel you to scan every single one of those roughly 200 public-facing IPs, even if they just point to a far smaller number of actual web app instances on the eight servers running them. Second, there's the matter of how you can make sure you actually get those web/apps & servers scanned with 100% certainty.
Regarding the question of whether you need to scan all almost-200 public-facing IPs, based on some specific guidance in the "Localized Load Balancers" section pasted below it looks like you do actually have an "out" against doing so.
On page 17 of the above-mentioned guidance (mentioned in other answers & comments also) for how an ASV-certified scanning authority must conduct its scans, this passage occurs:
Account for Load Balancers
If a scan customer has deployed load balancers, the scan may only see
part of the configuration beyond the load balancer. In these cases,
the following applies:
Localized Load Balancers:
The ASV must obtain documented assurance from the scan customer that
the infrastructure behind the load balancer(s) is synchronized in
terms of configuration.
If the scan customer is unable to validate a
synchronized environment behind their load balancers, the ASV must
disclose the inconsistency with the following Special Note on the scan
“Note to customer: As you were unable to validate that the
configuration of the environment behind your load balancers is
synchronized, it is your responsibility to ensure that the environment
is scanned as part of the internal vulnerability scans required by the
PCI DSS.” (Special Notes do not cause a scan failure or supersede any
established CVSS scoring.)
External Load Balancing Services:
The ASV must take into account the use of load balancing services
external to the scan customer’s environment that direct traffic
globally or regionally based upon source IP address location.
Depending on implementation, external load balancing services may
direct the ASV scan tools to only a regional subsection of a scan
customer’s environment. Thus, the ASV scan solution must accommodate
external load balancing scenarios to ensure that all IP addresses and
ranges provided by the scan customer are successfully scanned.
The use of load balancers, the configuration, and the customer’s
assurance must be clearly documented in the scan report.
(Blockquoting the above screwed up part of the formatting a little in the cut-and-paste vs. the original pdf, but the text of the content and the meaning of it remain completely unchanged.)
The only sensible interpretation I can give of that text is that scan customers who do their own load balancing merely have to certify, to the ASV's satisfaction, that all the servers you have behind the load balancer/s are "synchronized", so that you can say with a high degree of confidence that any ones that do happen to go unscanned because the load balancer/s just don't happen to forward traffic to them during a scan are in the same state as the ones that are successfully scanned. The language saying that entities in a localized load balancer situation don't have to scan every single externally-available IP is expressly different from the language that covers situations for non-localized load balancers; this implies the guidance authors knew and intended exactly that firms who use localized load balancing don't have to scan everything. Similarly, while the meaning of the rules for firms running localized load balancers here does contradict the repeated command in every other part of the ASV guidance that every external IP must be scanned, this section clearly sets down specifically-applicable guidance about what firms that have localized load balancers are allowed to do, which obviously overrides the more general guidance statements elsewhere. So, this must be exactly the "out" your acquirer was referring to, and to me it looks like they found a legitimate one.
What does keeping scanned and potentially-unscanned servers in "synchronization" mean? I agree with commenter AndyMac: it's likely the configuration images would have to be the same, or essentially the same. In terms of what a system looks like to maintain and prove that synchronization, I think a combination of using ordinary deployment tools carefully to ensure that the images you deploy are uniform + the use of change monitoring/comparison software to verify that everything remains as it should be would get the job done. But that's just a recommendation for one idea to look at; I'm sure there are other approaches.
One more important note: The text of the guidance above says if you can't show proper synchronization the ASV must put a little nastygram on your results saying so, but you don't fail the scan. Despite the possibility that some publically-reachable web apps & servers were missed by the ASV because of the load balancing, you are allowed to continue on in compliance with just an admonition that you really have to make sure to get everything scanned with your own vulnerability-scanning tools. So, yeah, unless your acquirer raises a stink it appears that not scanning all external IPs isn't a showstopper, even if you don't provide objective proof that any unscanned, publically-reachable web apps/servers are properly synchronized with scanned ones. (Ah, the security-first PCI council....)
So, moving on to quickly tackle the second point: actually getting all your publically-facing web apps/servers scanned. Really, you would like to get this done via the ASV. That saves you the hassle of either (a) implementing synchronization and documenting that for the ASV or (b) taking the little black mark on your scan results and relying solely on your own vulnerability-scanning tools and procedures to work perfectly every scan and catch everything that an ASV would catch. And the thing is... I really think you should be able to get the ASV scans to properly check each and every server (and all services & web apps available on each). I'll confess that I have little-to-no direct personal experience configuring load balancer-setups. But couldn't you could just:
(1) set aside a public IP address for the ASV to use that points directly to your firewall, bypassing load balancing;
(2) configure your firewall to forward all valid incoming traffic (ie. the traffic that you normally allow through the firewall) directed to that IP address to Server X, with Server X being the particular server (with the services/web apps it's running included) that you want to target on any particular scan, and;
(3) one scan after another, methodically change the server that gets scanned from that one IP until you're run through every publically-reachable thing you have?
Or you could go web app instance-by-web app instance, perhaps. (Although in that case you'd have to do 40 separate scans rather than 8, I suppose.) Point being: there has to be a way to allow the ASV to just bypass the load balancing and directly scan your setup. Like you said, you already do have some fixed, direct, "IP X goes to web app instance Y." rules in place. So, actually, you are already doing this to some extent. You should be able to just build on that, except changing the particular web app a public IP connects to from one scan to another. (I think.)
Anybody who does have some direct experience working with external, third-party vulnerability scans in a load balancer scenario want to chime in?
Anyway, hope the above helps. Cheers.
(UPDATE: Rewrote the above answer on 10/06 as it reflected a misunderstanding on my part of some facts. Overall conclusions didn't change, however.)