Sometimes clients need to understand that the effort required to meet the final 5% of their desires is going to be expensive. Your client might want to load native xls, but it's not in fact a business requirement. How about you tell them that you can do it, but it'll take six weeks more effort - the cost argument over "nice to have" might win then.
Now, are you using TEXT_CONVERT_XLS_TO_SAP or TEXT_CONVERT_XLS_INTO_SAP. You keep saying the latter, but that doesn't exist on my system. Accuracy is important.
One approach you might try is take a copy of TEXT_CONVERT_XLS_TO_SAP and fix the 255 char limitation. I've had a brief look at that and it is a complicated task - the main point of error is the definition of structure SOI_GENERIC_ITEM as defined in type group SOI. You certainly don't want to change that, so you'd have to do a lot of copying of SAP programs. Even then, the 255 limit may be built into the OLE interface, in which case you're stuck with that route.
If the files you're reading are xlsx files (as opposed to the old xls files), then you might like to check out abap2xlsx - http://scn.sap.com/community/abap/blog/2010/07/12/abap2xlsx--generate-your-professional-excel-spreadsheet-from-abap , This is normally used for generating geniune excel files, but it may also read them; I've not looked deeply into it. If it doesn't work, it might be a starting point, since xlsx is merely a cab file of xml, and therefore readily parsable. But as I say, it could take weeks, and so be very expensive.
My best advice is flag up the word "expensive" to your manager, and let him/her deal with it. You've hit an important restriction in SAP, to get round it is going to cost money and time.
I really think that the best way as what ever be the matter , most important is money matters.... Let me forward this matter in the way you expressed it and hope for the best