353

Suggested by Monika Kowalka Completed 

It would be nice to extend the Invoice Id to at least 30 length. It's not country specific, but world wide need. Unfortunately, Shorter number (what means wrong number of the invoice) will be reflected in bookings and in SAF-T file (XML files required by the Authority in Poland). Manual workaround exists, to manually correct the SAF-T file before sending to government, but this is not a good approach because still the wrong number is in the system and is not the same like on reports send to tax authority which can effect on penalties as well. From July 2019 there is an addition to the regulations of the information reported in SAF-T files, stating that if information is incorrect there is a charge of 500 PLN for each mistake.

Status Details

Released in 10.0.40

Feature name: Extend the length of invoice number for vendor invoice 

Comments (29)
  • Is there a release that is targeted for this change?
  • For our customers, not only from Poland we extended this field to 50 characters. 30 characters is too short.
  • First, to state the most important thing - there are no regulations in Poland restricting the length of an invoice number. In JPK, the most common reporting obligation in Poland, there is a de facto standard restriction of 256 characters in the TZnakowyJPK type for invoice number and the number of invoice corrected by this invoice (which actually can be several, customarily separated by a comma). Both in current JPK_FA and JPK_V7x reports. Some time ago, we did an in-depth analysis with one of our Clients and the longest number of supplier invoice was 59 characters from a utility company (the number included prefix, year, month, region and customer number, plus separators). About a quarter of invoices had numbers exceeding length of 20 characters. There is also a different de facto standard on the length of invoice number in Poland, which is the tax split payment transfer description format (in MPP mechanism - "mechanizm płatności podzielonej"), on which Polish banking system agreed among themselves to use and force it upon Polish entities - the limit in this format is 35 characters, which is based on SWIFT messages restrictions (some banks even interpret it as 30, because the invoice number requires "/INV/" prefix in the transfer description). But again, this is only a de facto/industry standard and is not required by law.
  • Also, another thing pointed out to me by a colleague: Aside from the invoice number field also the document number fields have to be changed accordingly, to fit the real invoice numbers.
  • Dear all,

    is this feature already published? I checked things in the Feature management and Release notes 2022 Wave 1 and can't find anything about it.

  • This seems to have been pushed back from earlier to March 2023. Hope this stays on track. Any insights?

  • Status is planned but it's not shown in any release wave. When can we expect this?

  • I don,t understand why there isn't any solution when this issue has a lot time. We have the same problem, and Microsoft doesn't have any ETA for when the fix would be available.

    The only solution could be extend the field by a customization but It´s a bad practice in my opinion for this case.

  • We have the same issue but we don't have news. Does anyone know if Microsoft is going to do the change? I think that in the end we will have to extend the 'Num' edt... and it is not a best practice...

  • Any update on which release this will come into?


    We have suppliers that regularly send invoices with references exceeding 20 characters.