The package I mentioned in post 2 is also AmpCalc. I think I understand the client's request. But I don't think I have the information that would satisfy that request.
What I infer is that they want you demonstrate that the software you plan to use is, in fact, capable of accurately performing the task you give it. One way to test it is to input a known problem with a known solution. But to get the "known solution," you need to use a different method, something other than the thing you wish to test.
For example, suppose you invent a new device, and call it a "calculator." Suppose you claim that it can perform arithmetic operations. So to prove it works, you hand a long list of numbers to an accountant, and ask that person to add them up. The accountant gives you back a total (and an invoice). Independently, you use your new invention to add up the same numbers. You get the same result. You have thereby verified that your invention works.
Any example calculations I could dig out of our project files will have been done using the same AmpCalc package that you need to test. So they would not comprise a "different method."
You could do a few sample calculations using AmpCalc, and have someone else do the same calculations using a different software package (e.g., ETAP, as Bob Fuhr suggested). That could give you a valid comparison, and could satisfy the client's request. The problem with this plan is that the Neher-McGrath methodology will not necessarily give you the same answers, even with the same inputs, if you apply different analytical techniques for solving the numerous, simultaneous, non-linear equations. You may or may not get an exact match. I once tried to use AmpCalc to derive the numbers that appear in some of the NEC tables that apply to underground ductbanks. My answers were close, but not exact matches.