Księgowość dla firm SaaS w Europie: przychody, Stripe, VAT i API

Firma SaaS w Europie ma cztery problemy księgowe, których nie ma sklep ani agencja: przychód wpływa, zanim zostanie wypracowany; operator płatności wypłaca środki w partiach, które nie odpowiadają fakturom; traktowanie subskrypcji na gruncie VAT zależy od tego, gdzie znajduje się klient i czy jest przedsiębiorcą; a każdy z tych faktów znajduje się w Państwa własnej bazie danych, a nie w arkuszu kalkulacyjnym. Odpowiedzią nie są dodatkowe godziny księgowania. Jest nią księga, która przyjmuje klientów, faktury i płatności z Państwa aplikacji przez API, zapisuje rozstrzygnięcie VAT dla każdej faktury i pozostawia rozliczenie podatkowe specjaliście.

Rozpoznawanie przychodów: plan roczny to nie roczny przychód

Gdy klient płaci z góry 1 200 € za rok, mają Państwo 1 200 € gotówki i 1 200 € zobowiązania zwanego przychodem przyszłych okresów (deferred revenue); co miesiąc, świadcząc usługę, wypracowują Państwo z tego 100 €. To podstawowa zasada stojąca za MSSF 15 i jego krajowymi odpowiednikami — i dlatego bilans firmy SaaS wygląda dziwnie dla założycieli, którzy dotąd obserwowali tylko rachunek bankowy.

Podstawowa zasada MSSF 15 brzmi: „jednostka ujmuje przychody w sposób odzwierciedlający przekazanie przyrzeczonych dóbr lub usług klientowi w kwocie odzwierciedlającej wynagrodzenie, do którego jednostka spodziewa się być uprawniona". Standard opisuje pięć kroków: identyfikacja umowy, identyfikacja zobowiązań do wykonania świadczenia, ustalenie ceny transakcyjnej, jej alokacja oraz ujęcie przychodu w momencie — lub w miarę — spełniania każdego zobowiązania. Subskrypcja jest zwykle spełniana w czasie, więc przychód ujmuje się w okresie subskrypcji.

To, które ramy rachunkowości faktycznie Państwo stosują, jest sprawą dla księgowego. Małe firmy w Niemczech, Francji, Belgii i Polsce zwykle raportują według krajowych zasad rachunkowości, a nie MSSF, a dla małych jednostek istnieją pewne uproszczenia. Mechanizm jest we wszystkich ten sam: gotówka z góry to najpierw zobowiązanie, a dopiero potem przychód. Różnią się szczegóły — czy opłata wdrożeniowa jest odrębnym zobowiązaniem, jak traktować rabat za płatność roczną, co robi darmowy miesiąc. Te kwestie wymagają potwierdzenia przez specjalistę.

Przychody przyszłych okresów (zobowiązanie z tytułu umowy)

Pieniądze otrzymane za usługę, którą nadal są Państwo winni. Zobowiązanie w bilansie, rozliczane w przychody w okresie świadczenia usługi.

Przychody naliczone (składnik aktywów z tytułu umowy)

Usługa, którą Państwo wykonali, ale jeszcze nie zafakturowali — plany rozliczane według zużycia i fakturowane z dołu generują to na koniec miesiąca.

MRR / ARR

Wskaźniki zarządcze, nie księgowe. Przydatne dla inwestorów; nie trafiają do sprawozdania rocznego.

Wypłaty Stripe to nie faktury

Wypłata (payout) Stripe to jeden przelew bankowy, który łączy wiele obciążeń, pomniejszonych o zwroty i opłaty, po opóźnieniu rozliczeniowym. Państwa przychodem są poszczególne obciążenia i stojące za nimi faktury; wypłata to jedynie sposób, w jaki gotówka do Państwa dotarła. Należy księgować je jako dwie różne rzeczy.

Własna dokumentacja Stripe jasno opisuje kolejność: „Stripe przesyła środki z dostępnego salda na Twoje konto bankowe w formie wypłat", zgodnie z harmonogramem wypłat konta, a „moment, w którym środki stają się dostępne, zależy od czasu rozliczenia". Płatność pojawia się najpierw jako saldo oczekujące „pomniejszone o wszelkie opłaty Stripe" i staje się dostępna później. Zalecanym punktem wyjścia do uzgadniania jest transakcja salda (balance transaction), którą Stripe tworzy „dla każdego rodzaju transakcji wpływającej na saldo konta Stripe lub z niego wypływającej" — typy takie jak charge, refund, stripe_fee, payout i currency_conversion.

Czyste podejście traktuje Stripe jako konto rozliczeniowe:

1. Gdy klient zostaje obciążony, zaksięgować sprzedaż: należność (lub bezpośrednio konto rozliczeniowe Stripe) w korespondencji z przychodem lub przychodami przyszłych okresów, z rozstrzygnięciem VAT ustalonym dla tego klienta.
2. Zaksięgować opłatę Stripe jako koszt w korespondencji z tym samym kontem rozliczeniowym, na podstawie transakcji salda, a nie szacunku.
3. Gdy wypłata pojawi się w wyciągu bankowym, przenieść kwotę wypłaty z konta rozliczeniowego na konto bankowe. Jeśli konto rozliczeniowe nie wraca do zera, czegoś brakuje — zwrotu, sporu, przewalutowania.

To, czy wystawiają Państwo formalną fakturę za każde obciążenie karty, zależy od klienta. Dla klienta biznesowego w UE faktura jest wymagana dla celów VAT; dla konsumenta często nie, choć wiele firm SaaS i tak ją wystawia, bo klienci o nią proszą. To faktura jest dokumentem niosącym rozstrzygnięcie VAT; paragon Stripe nie jest fakturą VAT, chyba że zawiera wszystko, czego faktura VAT wymaga.

VAT w UE od subskrypcji: B2C korzysta z OSS, B2B z odwrotnego obciążenia

Subskrypcja oprogramowania dostarczana online to „usługa świadczona drogą elektroniczną". Sprzedana konsumentowi w innym kraju UE jest opodatkowana tam, gdzie mieszka konsument; sprzedana przedsiębiorcy zarejestrowanemu do VAT w innym kraju UE jest opodatkowana tam, gdzie ma siedzibę ten przedsiębiorca, a on sam rozlicza VAT w ramach odwrotnego obciążenia. Dwóch klientów płacących te same 20 € może zatem generować cztery różne skutki w VAT.

Podsumowanie Komisji dotyczące miejsca świadczenia podaje trzy istotne tu zasady. Dla usług B2B „miejscem opodatkowania jest miejsce siedziby usługobiorcy" (art. 44 dyrektywy VAT). Dla usług B2C domyślnie jest to „miejsce siedziby usługodawcy" (art. 45) — ale „usługi telekomunikacyjne, nadawcze i elektroniczne świadczone na rzecz konsumentów są opodatkowane w miejscu zamieszkania usługobiorcy" (art. 58). Sprzedaż SaaS konsumentowi jest więc opodatkowana według stawki krajowej konsumenta, a nie Państwa.

Naliczanie konsumentom 27 różnych stawek krajowych oznaczałoby normalnie 27 rejestracji. Punkt kompleksowej obsługi (One Stop Shop, OSS) pozwala tego uniknąć: to dobrowolna procedura, uruchomiona 1 lipca 2021 r., w ramach której przedsiębiorca zarejestrowany w jednym państwie członkowskim deklaruje i płaci VAT należny we wszystkich pozostałych w jednej kwartalnej deklaracji. OSS obejmuje między innymi „transgraniczne świadczenie usług na rzecz osób niebędących podatnikami". Istnieje roczny próg 10 000 EUR dla transgranicznych usług TBE B2C — poniżej niego dostawca może nadal opodatkowywać we własnym kraju — a „procedury OSS są dla podatników dobrowolne". To, czy dla Państwa firmy właściwy jest OSS, próg czy rejestracja lokalna, wymaga potwierdzenia przez specjalistę.

Odwrotne obciążenie opiera się na tym, że nabywca rzeczywiście jest podatnikiem. VIES, system wymiany informacji o VAT Komisji, „umożliwia firmom szybkie uzyskanie potwierdzenia numerów VAT ich partnerów handlowych". Ta sama strona ogranicza to, co dowodzi sprawdzenie: dane „pochodzą z baz danych państw członkowskich, nad którymi służby Komisji nie mają kontroli", a potwierdzenie „samo w sobie nie daje prawa do zwolnienia dostaw wewnątrzwspólnotowych z podatku od wartości dodanej". Należy sprawdzić numer w chwili sprzedaży, zapisać wynik razem z fakturą i zachować dowody na to, gdzie znajduje się klient.

Zwroty, faktury korygujące i spory

Zwrot to nie usunięta faktura. W UE zafakturowaną sprzedaż koryguje się fakturą korygującą (notą kredytową), która odwołuje się do faktury pierwotnej, tak aby oba dokumenty pozostały, a VAT można było skorygować we właściwym okresie. Zwrot Stripe jest wówczas zapłatą tej faktury korygującej.

• Pełny zwrot w tym samym okresie VAT — faktura korygująca na pełną kwotę, zwrot zaksięgowany wobec niej, efekt netto zero.
• Częściowy zwrot — faktura korygująca na zwracaną część; przychody przyszłych okresów za anulowane miesiące są rozwiązywane, a nie rozpoznawane.
• Chargeback / spór — Stripe potrąca kwotę jako transakcję salda typu adjustment; traktować jak zwrot do czasu rozstrzygnięcia sporu, a następnie odwrócić, jeśli Państwo wygrają.
• Nieudany zwrot — Stripe zwraca środki na Państwa saldo (refund_failure); faktura korygująca pozostaje, strona płatności zostaje ponownie otwarta.

Wiele walut: jaki kurs i kiedy

Jeśli wyceniają Państwo w EUR, USD i GBP, księga nadal ma jedną walutę sprawozdawczą, a każda faktura w walucie obcej jest przeliczana po kursie z dnia wystawienia faktury. Różnica między tym kursem a kursem, po którym pieniądze faktycznie wpływają, to zysk lub strata kursowa, księgowana odrębnie od przychodu.

Stripe dodaje kolejną warstwę: obciążenie w USD wypłacane na rachunek bankowy w EUR jest przewalutowywane przez Stripe, a przewalutowanie pojawia się jako osobna transakcja salda (currency_conversion, z stripe_fx_fee, gdzie ma to zastosowanie). Zrealizowana różnica to rozbieżność między Państwa przeliczeniem z dnia faktury a przeliczeniem rozliczeniowym Stripe. Otwarte należności w walucie obcej na koniec roku są zwykle przeliczane ponownie po kursie zamknięcia, co daje różnicę niezrealizowaną; sposób ujęcia zależy od Państwa zasad rachunkowości i wymaga potwierdzenia przez specjalistę. Pełniejsze omówienie znajduje się na stronie kilka firm, kilka walut.

Co automatyzować przez API, a czego nie

Automatyzować należy zdarzenia, o których Państwa aplikacja już wie: klient się rejestruje, faktura subskrypcyjna staje się wymagalna, płatność się powiodła, wystawiono zwrot. Nie należy automatyzować osądów: który reżim VAT stosuje się w przypadku granicznym, jak alokować cenę pakietu, kiedy odpisać należność.

Minimalna integracja ma trzy przepływy. Państwa aplikacja tworzy klienta w księdze wraz z jego krajem i numerem VAT. Gdy Stripe (lub Państwa logika rozliczeniowa) wygeneruje fakturę subskrypcyjną, aplikacja tworzy odpowiadający jej projekt faktury w księdze, która rozstrzyga traktowanie VAT na podstawie faktów i waliduje dokument. Gdy Stripe zgłosi udane obciążenie, aplikacja zapisuje płatność. Przewodnik Stripe po webhookach wyjaśnia, dlaczego ostatni krok musi być idempotentny: „punkty końcowe webhooków mogą sporadycznie otrzymać to samo zdarzenie więcej niż raz", a Stripe „nie gwarantuje dostarczenia zdarzeń w kolejności ich wygenerowania". Księga, do której Państwo piszą, potrzebuje po swojej stronie tej samej ochrony — klucza idempotencji przy każdym zapisie.

Jak KRONENWERK to obsługuje

KRONENWERK to księga podwójnego zapisu z fakturowaniem, fakturami korygującymi, połączeniami bankowymi i publicznym API, zbudowana dla firm w Niemczech, Francji, Belgii, Polsce (w ograniczonym zakresie), Kanadzie i Stanach Zjednoczonych. Dla firmy SaaS istotnymi elementami są rozstrzygnięcie podatkowe, API i webhooki. Obsługiwane z ograniczeniami

• Rozstrzygnięcie podatkowe dla każdej faktury. Na podstawie kraju sprzedawcy i nabywcy, tego, czy nabywca jest przedsiębiorcą czy konsumentem, oraz rodzaju świadczenia każda faktura otrzymuje rozstrzygnięcie: stawka podstawowa, stawka zerowa, zwolnienie, odwrotne obciążenie, poza zakresem albo „wymaga danych" / „wymaga potwierdzenia przez specjalistę". Numery VAT nabywców są sprawdzane w VIES przy wystawianiu, a rozstrzygnięcie jest zapisywane razem z fakturą. KRONENWERK nie zgaduje.
• Klienci, faktury i płatności przez API. API pod adresem https://kronenwerk.org/api/extern/v1 przyjmuje POST /customers, POST /invoices/drafts i POST /transactions, każde z nagłówkiem Idempotency-Key. Projekty są wystawiane w produkcie po walidacji; API nie wystawia bezpośrednio faktur o mocy prawnej. Zob. podłączanie SaaS oraz API fakturowania.
• Webhooki. Podpisane dostarczenia dla invoice.issued, invoice.paid, invoice.cancelled, purchase.recorded i payment.recorded, z ponownymi próbami i Idempotency-Key dla każdego zdarzenia.
• Połączenia bankowe. Europejskie rachunki bankowe łączą się przez Enable Banking, kanadyjskie i amerykańskie przez Plaid, dzięki czemu wypłata Stripe pojawia się w księdze do uzgodnienia.
• Wiele walut i wiele firm. Faktury w walutach obcych, jedna księga na firmę, jeden klucz API na firmę.