Why PUESC rejects an RMPD and what to fix by RMPD500 code

A dispatcher clicks "Send" at 23:40, because the truck leaves at six. Instead of a reference number, an RMPD500 comes back: "R01.CodeLatin: Pole: [GoodsSenderName] zawiera znaki, które są niedozwolone w kodowaniu Latin1+PL". He fixes the name, sends again, and now gets "R02.PostalCodePl: niewłaściwy kod pocztowy PL: [nadawca, BRAK]". The third attempt goes through at 00:15. Every such line is a rule of the register, and every one of them can be passed at the first attempt if you know what it checks.

RMPD500 is the PUESC register's reply to a filing that failed validation: instead of a number, a list of messages arrives, each with a rule code and the field it concerns. This article takes apart the codes the register actually returns to carriers, using our platform's own data: 136 rejections for 242 filings sent through Sigil between 24 June and 15 September 2026. This is not market statistics; it is what one platform with a few dozen carriers sees.

In short: an RMPD500 returns a rule code in the form R01.CodeLatin, and the code is what tells you what to fix · Cyrillic in the consignor's name or town (R01) is the most frequent data rejection: the register accepts only Latin script plus Polish letters · a Polish address without a postal code in the 00-000 format (R02) is rejected, and BRAK in the postal code does not help · a start date in the past or an end date more than 9 days from filing (R06, R15, R26) is rejected at filing, amendment and cancellation · a locator not activated for SENT (R30) is refused even with a correct checksum · the border crossing and road number must match the PUESC dictionary · a closing RMPD103 sent after the register has closed the filing itself (R16) comes back as a rejection, and that is not a data error.

What an RMPD500 is and how to read it

RMPD500 is the register's technical rejection message. It is described in the Technical Specification of RMPD System Messages of 20 November 2024: every filing passes the list of rules R01–R14 from the specification and a few added later, and every rule broken produces a separate line in the list of messages. One RMPD500 may hold several lines, and then everything is fixed together, not one at a time.

A line has a fixed structure: rule code, rule name, an explanation in Polish, in square brackets the field or value that failed, and the time of the check. "R02.PostalCodePl: niewłaściwy kod pocztowy PL: [nadawca, BRAK]" is rule R02 on the Polish postal code, the consignor's field, the value BRAK.

Does an RMPD500 mean the filing was partly accepted? No. The filing is not registered and there is no number. After the correction a new RMPD100 is sent, not an RMPD101: only what the register has already accepted can be amended. What each document in the family does is in the article RMPD100, 101, 103, 104 and which document to file when.

Which codes the register actually returns

According to our platform's data, between 24 June and 15 September 2026, 242 RMPD100 filings were sent through Sigil. The register replied with an RMPD500 rejection 136 times; 60 filings received a rejection, one in four, and 38 of them were accepted after correction. The 136 replies carried 137 lines with the following rules.

Two caveats to this table. First: the 31 border-crossing lines and part of the R16 lines fall in the first weeks of the integration, when the crossing name in our dictionary differed from the PUESC name by one letter; the register compares strings literally. Second: lines are counted per message, not per carrier, and one stubborn error can produce ten lines from one filing, as R01 does in the table.

R01 Cyrillic where the register expects Latin

Rule R01 of the specification allows only Latin1 characters plus Polish letters in text fields: a-zA-Z0-9, punctuation and ąćęłńóśźżĄĆĘŁŃÓŚŹŻ. The consignor's name from the CMR, "ТОВ Агротрейд" in Cyrillic, does not pass, nor does the apostrophe in "Карп'юк" typed as the character from a Ukrainian keyboard, which is not in Latin1.

The register names the field in brackets: GoodsSenderName is the consignor's name, GoodsSenderAddressCity the consignor's town, journeyStartCity the town where the journey starts. In our data all 19 R01 lines concerned the consignor and the start town in Ukraine: the carrier copied box 1 of the CMR as printed, in Cyrillic.

What to do: transliterate by the rules used in the international passport or on the consignment note, and the same way in every field of the filing. ТОВ becomes TOV, Карп'юк becomes Karpiuk. This does not conflict with the rule of copying the CMR verbatim: the register physically does not accept Cyrillic, and a transliteration is the same name in another alphabet, not a different name.

R02 a Polish address without a postal code

Rule R02: when a party's address has the country PL, the postal code must have the format 00-000. The rule applies only to Polish addresses; for Ukraine or Germany the format is not checked.

In our data this is 12 lines for 7 filings, almost all with the same value: [nadawca, BRAK] or [odbiorca, BRAK]. The dispatcher knew that an empty street or house number is filled with the word BRAK, and did the same with the postal code. For the code it does not work: BRAK is allowed only in the Street and HouseNumber fields (rule R04).

What to do: find the Polish party's postal code on the invoice, the stamp or in the Poczta Polska directory and enter it as five digits with a hyphen. If it is not on the CMR, this is exactly the case where the data are requested from the consignor, not invented.

R06, R15, R26 dates the register counts from today

Three rules about one thing: the start date cannot be in the past, and the end date cannot be more than 9 days from the day of filing. R06 applies at registration, R15 at amendment via RMPD101, R26 at cancellation via RMPD104.

The most common situation in our data, 8 filings out of 9 R06 lines: the dispatcher files in the evening for a run planned for 10 days and sets the end date on the tenth day. The register counts 9 days from the filing date, not the start date: "Data zakończenia transportu (2026-09-18) jest późniejsza niż maksymalna dozwolona data (2026-09-17)". The second situation: a filing prepared yesterday, sent after midnight, and the start date is already "wcześniejsza niż dzisiejsza data", earlier than today.

R26 appears when the carrier wants to cancel a run that by its dates has already started: "Data rozpoczęcia przewozu towaru: [2026-09-03] nie może być wcześniejsza od bieżącej w chwili anulowania". After the start date cancellation is impossible; closing remains.

What to do: file no earlier than 9 days before the end of the run, and for a longer run set the end date within 9 days and extend it with an RMPD101 en route. A filing prepared in the evening should be sent before midnight Polish time, or the start date checked after midnight.

R30 the locator exists, but not for SENT

Rule R30 checks not the format of the locator number but whether the device is activated to transmit position under SENT filings: "podany numer nie jest aktywowany do rejestracji położenia w ramach zgłoszeń SENT". The checksum is right, the device exists, but in SENT-GEO it is not marked as active for this carrier.

In our data this is 17 lines for 8 filings, and the same number repeated several times: the dispatcher saw that the number was correct and sent again. What was missing was not a digit but the activation.

What to do: open the locator service on PUESC and check the device's status; activate it for the carrier or enter another one that is already active. The backup locator is checked the same way.

Border crossing and road number outside the dictionary

This rejection comes without a rule code: "No borderCross for routePlace: Dorohusk - Jagodzin, routeNumber: DK12". The register keeps a dictionary of road crossings in which every entry is a pair of crossing name and road number, and it compares both values literally. "Dorohusk - Jagodzin" with road DK12 was not in the dictionary; there was a different entry for the same crossing.

In our data this is 31 lines for 8 filings, the most in the table, and almost all from the first weeks of the integration: the crossings dictionary on our side differed from the PUESC one. That is fixed, but the mechanism is the same for anyone filling in the form on the portal: the crossing name is not typed but chosen from a list, and the road comes with it.

What to do: in sections 3.7 and 3.8 choose the crossing from the dictionary, not from memory; if the entry point is not on the list, use the "Miejsce spoza listy" field (place outside the list) with coordinates rather than typing a name into the crossing field.

R16 a closing the register has already done itself

"R16.RMPD103Rejected: Przesłany komunikat nie jest aktualnie obsługiwany" comes in reply to an RMPD103 when the filing is no longer in a status from which it can be closed: the register closed it automatically after the planned end date (status 5), or it is cancelled. This is not a data error and there is nothing to fix.

In our data this is 25 lines for 16 filings: the closing went out the day after the planned end date, and the register had already closed them itself. What each status means and when to close yourself is in the help article Checking RMPD statuses.

A rejection with a code is an answer from the register; when the register does not answer at all, a different procedure applies, with a replacement document to GITD, taken apart in What to do with RMPD and SENT when PUESC is down.

If there is no PUESC account yet, every screen of the registration form is walked through in Registering on PUESC as a non-EU carrier, step by step.

What to do

1. 1Read the rule code, not just the text. R01 is characters, R02 postal code, R06 dates, R30 locator. The code tells you which field to open.
2. 2Fix everything from one RMPD500 together. Several lines are several errors, and one at a time they cost several attempts.
3. 3Transliterate Ukrainian names and towns as in the international passport, in every field of one filing. Cyrillic never passes.
4. 4For the Polish party find the postal code in the 00-000 format. BRAK works only for the street and house number.
5. 5Set the end date no more than 9 days from the day of filing, not from the day of entry. Extend a longer run with an RMPD101.
6. 6Before the first run check on PUESC that the locator is activated for SENT-GEO. A correct number without activation is an R30.
7. 7Choose the border crossing from the dictionary, and after the planned end date check the status before closing: a filing closed by the register needs no closing.

What not to do

• ✗Do not resend the same filing unchanged. The RMPD500 repeats word for word, and every attempt leaves a trace in the register.
• ✗Do not put BRAK in the postal code. Rule R04 allows it only in the street and house number.
• ✗Do not copy a Cyrillic name from the CMR into the filing. The register accepts only Latin1 with Polish letters; a transliteration is the same name.
• ✗Do not count 9 days from the entry date. The register counts from the filing day, and a ten-day run needs an RMPD101 en route.
• ✗Do not cancel a run after the start date. R26 refuses; after the start a filing can only be closed.

Where Sigil fits in

Sigil reads the RMPD500 for the carrier: the rule code and the field name from the brackets are translated into the name of the same field in the form, and the dispatcher sees exactly what to fix, in their own language, without the register's Polish text. Some rules the system checks before sending: plate format, the word BRAK, the Polish postal code, date limits, the locator checksum, so those rejections never reach the register. Locator activation on PUESC and the transliteration of names are confirmed by a person: the system does not change CMR data on its own.

A rejection costs minutes, not hours: on our data PUESC answers a declaration in 4 seconds, and the whole cycle from CMR photo to number takes a median of 6 minutes; what really drags a filing out is in How long an RMPD really takes, from CMR photo to number.

Sigil handles RMPD declarations. The SENT notification for the goods is filed by the consignor or the consignee.