First, there's always a good chance nobody on the client side actually cares about this. RFPs tend to come with hundreds of questions, most of which are put in as requirements by completely detached departments to make them feel important, but don't actually matter. If something is important, it can be negotiated. For example, if the pen test is important, you can get the client to agree to sign the contract with a clause that says if they don't get pen tests results by X date the contract is void.
Second, well, what is a pen test, really? If you ever called one of your APIs to validate that your authorization or authentication code works, or you've validated that your AWS security groups are blocking external traffic to your database, congrats, you've performed a "pen test"! The client won't consider that sufficient, of course, but it's a justification for an answer on an RFP, at least. If they want more details, as they do in this case, they can always schedule a follow-up call or ask to see the pen test results document.
This situation reads like an engineer who needs a bit of business/sales experience more than anything. In their discussion with the client, you can start with "we've currently only done in-house penetration testing, but are looking to contract an external vendor to do penetration testing by X date." Assuming you've done any testing, this is a true statement, and the client can determine if that's sufficient.
The real solution to this is to get SOC2/ISO27001 certification, though, which makes a lot of these RFP headaches go away.