Czasem faktura musi zostać skorygowana. Za wysoka kwota, nieprawidłowa stawka VAT, zwrot towaru: rozwiązaniem jest nota kredytowa. W standardzie UBL istnieją dwa sposoby wysłania noty kredytowej. Są technicznie bardzo różne, ale służą temu samemu celowi. Wybór wariantu zależy od używanego oprogramowania, odbiorcy i profilu Peppol.

Pierwszy wariant to odrębny typ dokumentu UBL: CreditNote. Ten dokument korzysta z własnego schematu XML (CreditNote-2) i ma własne nazwy elementów. Zamiast InvoiceLine występuje CreditNoteLine, a zamiast InvoicedQuantity pojawia się CreditedQuantity.

<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2">
  <cbc:ID>CN-2026-0001</cbc:ID>
  <cbc:IssueDate>2026-03-08</cbc:IssueDate>
  <cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>F-2026-00042</cbc:ID>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <!-- strony, podsumowania VAT itp. -->
  <cac:CreditNoteLine>
    <cbc:ID>1</cbc:ID>
    <cbc:CreditedQuantity unitCode="EA">5</cbc:CreditedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">125.00</cbc:LineExtensionAmount>
    <!-- artykuł i cena -->
  </cac:CreditNoteLine>
</CreditNote>

Wszystkie kwoty w CreditNote są dodatnie. Sam fakt, że jest to dokument CreditNote, jednoznacznie wskazuje, że chodzi o korektę. Element BillingReference odwołuje się do oryginalnej faktury, która jest kredytowana.

• Własny węzeł główny XML (CreditNote zamiast Invoice)
• Własne nazwy elementów (CreditNoteLine, CreditedQuantity)
• Wszystkie kwoty są dodatnie
• Szeroko obsługiwany przez odbiorców Peppol
• TypeCode to 381 (nota kredytowa powiązana z fakturami)

Drugi wariant wykorzystuje zwykły dokument Invoice, ale z ujemnymi kwotami. InvoiceTypeCode pozostaje 380 (faktura handlowa). Technicznie jest to zwykła faktura, ale dzięki ujemnym kwotom pełni funkcję noty kredytowej. Jest to holenderska konwencja opisana w UBL Ketentest biura badawczego GBNED.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ID>CN-2026-0001</cbc:ID>
  <cbc:IssueDate>2026-03-08</cbc:IssueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>F-2026-00042</cbc:ID>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <!-- strony, podsumowania VAT itp. -->
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="EA">-5</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">-125.00</cbc:LineExtensionAmount>
    <!-- artykuł i cena -->
  </cac:InvoiceLine>
</Invoice>

W tym wariancie ilości i kwoty są ujemne. Kwota VAT i kwota do zapłaty również są ujemne. Struktura jest poza tym identyczna ze zwykłą fakturą.

• Ten sam węzeł główny XML co zwykła faktura (Invoice)
• Te same nazwy elementów (InvoiceLine, InvoicedQuantity)
• Kwoty i ilości są ujemne
• InvoiceTypeCode to 380 (zwykła faktura); znak ujemny wskazuje, że chodzi o kredytowanie
• Prostsza do wdrożenia dla oprogramowania wysyłającego (nie wymaga osobnego typu dokumentu)
• Opisana w GBNED/UBL Ketentest jako standardowa holenderska praktyka

Wybór zależy od trzech czynników:

Co obsługuje Państwa oprogramowanie? Niektóre oprogramowanie księgowe domyślnie generuje dokument CreditNote, inne ujemną Invoice. Jeśli oprogramowanie obsługuje tylko jeden wariant, wybór jest przesądzony.

Czego oczekuje odbiorca? W ramach Peppol oba warianty są obsługiwane przez profil BIS Billing 3.0. W praktyce jednak systemy odbierające mogą mieć preferencje. W razie wątpliwości dokument CreditNote jest bezpieczniejszym wyborem, ponieważ jest wariantem bardziej jednoznacznym.

Jakiego profilu Peppol Państwo używają? Standardowy profil BIS Billing 3.0 akceptuje zarówno schemat CreditNote (381), jak i schemat Invoice z ujemnymi kwotami (380). Nie wszystkie profile obsługują oba warianty. Należy to zweryfikować w przypadku korzystania z profilu branżowego.

Wskazówka: w eConnect można wysyłać oba warianty. Platforma automatycznie rozpoznaje, czy jest to dokument CreditNote czy ujemna Invoice, i przetwarza je w ten sam sposób. Jeśli odbiorca oczekuje konkretnego formatu, PSB automatycznie przekształca dokument.

Oba warianty stosują przeciwne konwencje znaków. Poniższe zestawienie pokazuje, jak to samo kredytowanie (5 sztuk po 25 euro) wygląda w obu wariantach:

Kluczowa różnica tkwi w interpretacji. W CreditNote odwrócenie znaku jest domyślne: wszystkie kwoty są dodatnie, ale typ dokumentu jednoznacznie wskazuje, że chodzi o kredytowanie. W ujemnej Invoice to same ujemne kwoty pełnią funkcję wskaźnika.

PriceAmount (cena jednostkowa) jest dodatni w obu wariantach. Jest to określone w regule walidacji BR-27. W ujemnej Invoice kwotę czyni się ujemną poprzez ilość lub LineExtensionAmount, a nie poprzez cenę jednostkową.

Warianty wyszukiwania: "nota kredytowa Payee własna organizacja", "nota kredytowa odbiorca dostawca", "Payee zamiast dostawcy nota kredytowa", "Supplier Customer zamiana przy nocie kredytowej", "do zapłaty vs do otrzymania PayableAmount".

Winien i ma nie oznacza zamiany stron. AccountingSupplierParty pozostaje dostawcą, a AccountingCustomerParty pozostaje nabywcą, nawet na nocie kredytowej. To, czy nabywca musi zapłacić, czy otrzymać, wynika z typu dokumentu i znaku PayableAmount (patrz tabela powyżej): w przypadku ujemnej faktury (380) PayableAmount jest ujemny, więc nabywca otrzymuje; w przypadku CreditNote (381) kwoty są dodatnie i kredyt wyraża typ dokumentu.

Opcjonalna PayeeParty jest istotna tylko wtedy, gdy kwota musi zostać przekazana innej stronie, na przykład w faktoringu. Nie jest to to samo co „odbiorca kredytu" w sensie potocznym. Jeśli własna organizacja pojawia się w polu Payee lub odbiorca, podczas gdy Supplier i Customer są już poprawne, należy najpierw sprawdzić, czy chodzi o opcjonalne dane PayeeParty/PaymentMeans, przed zgłoszeniem korekty.

eConnect nie nadpisuje ról stron przy odbiorze i nie stosuje automatycznie wcześniejszej korekty Payee, gdy źródłowy UBL jest już prawidłowy. Faktury są przetwarzane tak, jak zostały przesłane; nieprawidłowe dane stron muszą zostać poprawione przez nadawcę w źródłowym UBL. Zob. również Przetwarzanie UBL.

Warianty wyszukiwania: "silent price/quantity sign change during BIS3 transformation", "negative unit price mapping", "ujemna cena jednostkowa", "zamiana znaku cena ilość", BR-27 PriceAmount.

Cena netto pozycji (BT-146 / PriceAmount) nie może być ujemna (BR-27). Przy ujemnej Invoice (TypeCode 380) cena jednostkowa pozostaje dodatnia; znak minus jest na ilości (BT-129) oraz na kwotach wiersza i sumach. CreditNote (381) utrzymuje cenę i ilość dodatnie; kredytowanie wynika z typu dokumentu. Przy normalizacji lub transformacji między schematami CreditNote i ujemnej Invoice (m.in. przez PSB) ciche przeniesienie znaku między ceną a ilością to oczekiwane zachowanie w celu przestrzegania BR-27 — nie błąd wtyczki. Dane źródłowe z ujemnymi cenami jednostkowymi: mapuj po stronie integracji na dodatnią cenę plus znak na ilości lub typie dokumentu, zgodnie z tabelą powyżej.

UBL Ketentest biura badawczego GBNED opisuje wyłącznie wariant 380 (ujemna Invoice) dla not kredytowych. Wiele holenderskich pakietów księgowych z certyfikatem "UBL Ready" domyślnie generuje zatem ujemną Invoice. Peppol BIS 3.0 natomiast standardowo stosuje schemat CreditNote (381) z dodatnimi kwotami.

Oprogramowanie odbierające musi obsługiwać oba warianty. PSB w razie potrzeby automatycznie przekształca między dwoma schematami, dzięki czemu odbiorca otrzymuje dokument w formacie oczekiwanym przez swoje oprogramowanie.

Niezależnie od wybranego wariantu, prawidłowa nota kredytowa zawsze zawiera:

• Odwołanie do oryginalnej faktury poprzez BillingReference / InvoiceDocumentReference
• Prawidłowy TypeCode: 381 dla schematu CreditNote, 380 dla ujemnej Invoice
• Prawidłowe obliczenie VAT (zgodne z oryginalną fakturą)
• Tę samą walutę co oryginalna faktura

Nota kredytowa bez odwołania do oryginalnej faktury nie jest akceptowana przez wiele systemów odbierających. Odwołanie to jest ponadto niezbędne dla ewidencji VAT: w przypadku kontroli musi być możliwe prześledzenie, która faktura została skredytowana.

Warianty wyszukiwania: "pomoc nota kredytowa", "utworzyc note kredytowa", "nota kredytowa portal", "nota kredytowa juz wyslana faktura", "utworzyc fakture korygujaca Invoice Portal", "skorygowac zduplikowana fakture", "duplikat faktury nota kredytowa", "wyslano dwa razy te sama fakture skorygowac", "jak utworzyc note kredytowa".

Faktury wysłanej przez Peppol (lub inny kanał) nie można już edytować -- tylko faktury będące w stanie roboczym mogą być modyfikowane. Błąd w wysłanej fakturze koryguje się zawsze nowym dokumentem, nigdy modyfikacją oryginału. W portalu nie ma osobnego przycisku Nota kredytowa; wybierz typ dokumentu Faktura korygujaca (etykieta UI). Standardowy przebieg księgowy:

Konwencje znaków: przy schemacie CreditNote (381) kwoty muszą być dodatnie -- typ dokumentu sam wyraża kredytowanie. Przy ujemnej fakturze (380) należy uczynić ilość ujemną, zachowując cenę jednostkową dodatnią (BR-27). Jeśli ilości zostaną przypadkowo pozostawione jako dodatnie, powstaje dodatnia "faktura kredytowa", która nie może być przetworzona jako nota kredytowa.

Wymagany nowy numer: jeśli tworzysz nową fakturę jako kopię oryginału, zawsze przypisz nowy numer. Zobacz też Wykrywanie duplikatów fatur.

Oprócz TypeCodeów 380 i 381 istnieje TypeCode 384 (faktura korygująca). Ten typ dokumentu może zawierać zarówno kwoty dodatnie, jak i ujemne w tym samym dokumencie, przeznaczony dla przypadków, gdzie jednocześnie kredytuje się i dofakturowuje. NLCIUS zaleca 384 zamiast not kredytowych dla czytelności. Uwaga: TypeCode 384 nie jest dostępny we wszystkich profilach -- na przykład nie jest obsługiwany w standardowym profilu BIS Billing V3.

Nie jest wymagane kredytowanie faktury w całości. Można wysłać częściową notę kredytową, która koryguje jedynie część oryginalnej faktury. Jeśli na przykład kredytowane są dwa z dziesięciu zafakturowanych artykułów, nota kredytowa zawiera tylko te dwie pozycje z odpowiednimi kwotami.

Wskazówka: jeśli Państwo wysyłają faktury za pośrednictwem PSB API, przy pobieraniu dokumentu mogą Państwo za pomocą parametru targetDocumentTypeId określić, czy chcą otrzymać wariant CreditNote czy Invoice. PSB może dokonać transformacji między dwoma wariantami w locie.