Skip to Content
Technical Articles
Author's profile photo Giovani Quadros

Do you need to extend RBKP-XBLNR to handle more characters? You’re not alone.

Let me guess: there is a new legal requirement and you would need to have more characters to handle references for MM invoices in the XBLNR field.

And let me guess again: It’s a requirement from China, correct?

Maybe the second guess was incorrect, but the content here applies to many different scenarios as well.

And maybe the first guess was incorrect too. If you don’t have a legal requirement, but you’re just curious about the content, you may find something curious about SIM cards in this blog post.

If you really have that requirement, let me tell you that you are not alone.
As a Support Expert, I’ve been taking over many cases from customers that had the same question as yours in the last months. And I’m here to give you a brief explanation about the invoice reference field (and about SIM cards too).

For a short answer, you can check KBA 2580037 – MIRO/MIR7: Extended lengths for INVFO-XBLNR.

You can also stay in this post and discover a curious fact about SIM cards:

A curious fact about SIM cards


Did you know that many of them can handle only 16 characters for the contact names you store in them?

And that’s a good example to illustrate what’s happening here.

You may ask: “Well, I have lots of contacts with long names and never had to shorten their names when adding them as my contacts”. It is possible to do so, however you are probably storing your phone contacts on a cloud service, for example.

But now suppose that you are buying a new smartphone from a different brand. You’d like to transfer the contacts to the new phone, but your contacts are saved under the cloud service for brand A, which can’t be accessed by the cloud service for brand B. As a quick workaround, you decide to transfer the contacts to your SIM card, then transfer them to the other cloud service once the SIM card is inserted into the new phone. Simple, right?

Well, no. As your SIM card can only handle 16 characters for phone contacts, you’d have to shorten many contact names if you’d like to keep that approach to transfer contacts.

Okay, that workaround would actually take some minutes. Not a big problem. But let’s check XBLNR field again and discuss the impacts if the character limit were extended to 20 or 25 characters.

What if XBLNR field were simply extended?

Basically, lots of database tables, lots of programs and also lots of custom programs rely on the 16-character limit when they are reading invoice data. If XBLNR field were simply extended, it could break many functionalities in an unexpected way, causing potential system errors and database inconsistencies.

It would be a high-risk approach to perform that change, as many SAP systems around the globe could be affected.

This is why, from a software-design perspective, it is much better to keep the 16-character limit (as it has been defined since the beginning).

How to handle more characters?

Well, the requirement still persists. This is why, to handle it, SAP suggests that you use the Text field (SGTXT) to store more characters for your invoice reference.

To handle invoice control for that reference (e.g. suplicate invoice check) when using a different field, you can use BAdI MRM_HEADER_CHECK (you can find a brief explanation about it in SAP note 1156325) and implement your own logic to verify the invoice header.


Software design is not an easy process, and all elements (such as input fields) are conceived in such a way that many requirements can be fulfilled. However, those requirements may change throughout time and, many times, the system can be adapted for those new requirements. But, sometimes, even a simple adaptation like a character-limit increase is not feasible, and the safest path is to use a workaround.

If you have that specific requirement and you were stuck,
I hope that the information clarifies, goodbye and good luck.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Chad He
      Chad He

      Dear Giovani Quadros,

      As a Chinese speaker, I'm a little care about your 2nd guess.

      Are there some business cases often use this field to save some long information in China?

      It's a standard solution or just customary practice?


      Thanks & Regards,



      Author's profile photo Giovani Quadros
      Giovani Quadros
      Blog Post Author

      Hi Chad, I don't have too much information about that. Generally, Customers only mention that there is a China regulation act for electronic invoices.

      One of the Customers attached a document whose title refers to this announcement of Shanghai Municipal Tax Service (the website is currently offline, but I've got the cached link).

      So it might be a local requirement from Shanghai.

      Author's profile photo Chad He
      Chad He

      Hi Giovani,

      Thank you for your reply.

      I found the original link

      Announcement of the Shanghai Municipal Tax Service of the State Taxation Administration on Further Conducting the Pilot Program of Receiving Fully Digitized Electronic Invoices

      And I found Chinese version:



      Shanghai is a pilot of FEDIs(Fully Digitized Electronic Invoices), but it will be fully rolled out in China. So it not just a Shanghai local requirement any more.

      As descripted in the announcement No.4,

      The invoice number of FDEI is 20 digits, among which: the first and second digits represent the last two digits of the calendar year, the third and fourth digits represent the administrative division code of Shanghai, the fifth digit represents the information on FDEI issuing channel, and the sixth to twentieth digits represent the sequential code and other information.

      According to this, RBKP-XBLNR with 16-digits is not long enough to fill with FDEI Number.(20-digits).