Hi Ankur,
the way you describe it, a custom development seems like the last straw 
. That is, if the cooperation between CMB and AMEX definitely rules out that AMEX can change the format to one single currency (as it should be), RPRCCC_READ_KR1025 wont be able to read these files (as you already analysed correctly and as your provided screenshot shows.).
For some food for thought: We are using Airplus (with a company account) with ATX Format. That's a completely different situation than yours and technically it works out relatively good. However, we did have some problems with the functional content of the ATX Files, because certain service providers aren't able to return their data with a reference key (PERNR, REINR, Itemization). For this, I have created a WDA based Scenario which does the following:
- the original File is read in, validated and parsed
- the power user using the scenario can manipulate certain items that qualify for certain service providers and are missing any reference to the SAP data whatsoever. Basis for that manipulation are paper based documents which do have a reference (better don't ask....)
- the data is parsed, validated and converted back into an ATX-File
- the manipulated/converted/corrected ATX file is submitted to the standard program RPRCCC00
- everybody's happy
This makes the business process a bit clumsy but it works out and it does work out a lot better than toying around with the CCC-Buffer and the standard file correction reports.
Maybe you can build something similar and mix your two currencies into one without falsifying the sums to "prepare" the files for RPRCCC_READ_KR1025. ;-/
Cheers, Lukas