


Firma, która sprzedaje w dwóch albo trzech krajach, potrzebuje systemu przygotowanego na to od pierwszego dnia — bo dokładanie drugiego kraju do aplikacji zbudowanej pod jeden kończy się przepisywaniem połowy logiki. Nie chodzi przy tym o tłumaczenie interfejsu, bo to akurat jest najprostsza część. Chodzi o waluty, podatki, płatności, adresy i o to, co system ma zrobić, gdy klient z Belgii kupuje towar leżący w magazynie pod Poznaniem.
Poniżej lista decyzji, które przerabiamy z klientami prowadzącymi firmy za granicą. Nie każdą trzeba podjąć od razu, ale każdą trzeba przewidzieć.
Zwykle mniej, niż się wydaje, ale konsekwencje są większe, niż się wydaje. Sama prezentacja cen w euro i złotówkach to drobiazg. Problem zaczyna się przy pytaniu, w czym trzymasz cenę źródłową. Jeśli w jednej walucie i przeliczasz kursem, to każdy skok kursu zmienia Ci ceny w drugim kraju — i pewnego ranka masz produkt za 19,97 zamiast 19,99. Jeśli trzymasz osobne cenniki dla każdego kraju, masz spokój z zaokrągleniami, ale ktoś musi je aktualizować.
Do tego dochodzą zwroty i korekty. Klient zapłacił w euro, kurs się zmienił, zwracasz — po jakim kursie? To pytanie do księgowości, ale odpowiedź musi trafić do systemu, bo później nikt ręcznie tego nie policzy.
Praktycznie zawsze doradzam: jedna waluta rozliczeniowa w bazie, ceny sprzedażowe per kraj, kurs zapisywany razem z zamówieniem. Ostatni element brzmi jak techniczny szczegół, a ratuje skórę przy każdej reklamacji sprzed pół roku.
Tłumaczenie interfejsu jest tanie i szybkie. Kosztowna jest reszta: opisy produktów, regulamin, polityka prywatności, mailingi transakcyjne, komunikaty błędów, faktury i to, co zobaczy klient, gdy płatność się nie powiedzie.
Z doświadczenia: regulamin i polityka prywatności muszą być w języku kraju, w którym sprzedajesz — to nie jest miejsce na oszczędzanie ani na tłumacza automatycznego bez korekty. Opisy produktów też, bo one sprzedają. Panel administracyjny, z którego korzystasz Ty i Twoi ludzie, może spokojnie zostać po polsku i zwykle tak właśnie robimy — nie ma sensu utrzymywać drugiej wersji językowej czegoś, co widzi pięć osób.
Ważne technicznie: przygotowanie bazy pod wiele języków na starcie kosztuje niewiele, a doklejanie tego później to jedna z najbardziej upierdliwych przeróbek, jakie znam. Struktura z osobnymi wpisami dla każdej wersji językowej powinna być od początku, nawet jeśli na początku wypełnisz tylko jedną.
Rozliczenie podatku to temat dla Twojej księgowości, ale system musi umieć trzy rzeczy. Po pierwsze: przypisać właściwą stawkę do właściwego kraju i typu towaru, bo stawki różnią się między krajami i potrafią się zmieniać. Po drugie: rozpoznać, czy kupujący jest firmą z ważnym numerem VAT-UE — wtedy dokument wygląda inaczej niż przy sprzedaży konsumentowi. Po trzecie: prowadzić osobną, ciągłą numerację faktur zgodną z tym, czego oczekuje Twój kraj rejestracji.
Jeśli sprzedajesz konsumentom w kilku krajach Unii, prędzej czy później pojawi się temat procedury OSS i progów sprzedaży. System powinien przynajmniej wiedzieć, ile sprzedałeś do którego kraju, żebyś nie dowiadywał się tego z Excela w kwietniu. To zwykle jeden raport i kilka godzin pracy, a oszczędza dużo nerwów.
Osobno warto przygotować się na e-faktury. W Unii przygotowywane są zmiany, które w perspektywie kilku lat obejmą fakturowanie transakcji między firmami. Nie trzeba tego wdrażać dziś, ale przy projektowaniu modułu faktur pytam klientów, czy chcą, żeby dało się w przyszłości podpiąć format strukturalny. Odpowiedź „tak" kosztuje na tym etapie prawie nic.
Bo klient płaci tym, co zna, a nie tym, co masz. W Holandii ogromna część zakupów online idzie przez iDEAL i brak tej opcji potrafi po prostu zabić sprzedaż. W Belgii ten sam mechanizm ma Bancontact, w Norwegii Vipps, w Danii i Finlandii MobilePay, w Szwecji Swish. Do tego w całym regionie mocno obecna jest Klarna z odroczoną płatnością.
Karta i szybki przelew to dziś minimum, ale nie przewaga. Jeśli wchodzisz na konkretny rynek, sprawdź, czym płaci się tam naprawdę, i dopiero potem wybieraj operatora płatności — bo to on decyduje, które metody będziesz mógł włączyć. Zmiana bramki płatniczej w połowie życia sklepu jest wykonalna, ale kosztuje więcej niż wybranie właściwej na starcie.
Formularz adresowy zaprojektowany pod Polskę wywraca się przy pierwszym kliencie z zagranicy. Holenderski kod pocztowy ma format „1234 AB", irlandzki Eircode wygląda zupełnie inaczej, w wielu krajach numer domu jest osobnym polem i nie da się go wpisać po nazwie ulicy. Jeśli walidacja jest zbyt sztywna, klient nie kończy zamówienia — i nigdy się nie dowiesz dlaczego.
Podobnie z kurierami: cennik, wagi, terminy i punkty odbioru różnią się per kraj, a klient chce to zobaczyć przed płatnością, nie po. To zwykle najbardziej pracochłonna część takiego projektu, więc lepiej ją policzyć na starcie, niż odkryć w trakcie.
Nie od przepisywania wszystkiego. Zwykle wystarczy przygotować fundament — strukturę wielojęzyczną, walutę zapisywaną przy zamówieniu, stawki podatku jako dane, a nie jako liczby w kodzie — i dopiero wtedy dokładać kolejne rynki, gdy pojawi się w nich sprzedaż. Taki fundament to kwestia kilkudziesięciu godzin pracy, czyli mniej niż jeden miesięczny pakiet (5000 zł netto za 40 godzin), a późniejsze wejście na nowy kraj przestaje być projektem od zera.
Jeśli sprzedajesz przez sklep, więcej o samym rozwoju i utrzymaniu części online znajdziesz w kompleksowej obsłudze sklepu internetowego. A jeśli budujesz coś większego niż sklep — portal, marketplace, panel dla klientów B2B — zajrzyj do oferty albo od razu opisz nam swój przypadek. Policzymy to pod Twoje kraje, a nie pod średnią.
Data publikacji: 24 sierpień 2026 rok, czas aktualizacji: 2026.08.24, rodzaj publikacji: "Porada".