Wstęp
Skąd bierze się ta kwota, gdy na ekranie portfela klient widzi, że dostępnych jest 850 EUR?
Ryzykowna odpowiedź: “W bazie danych znajduje się pole bilansu, które aktualizujemy za każdym razem, gdy coś się dzieje”.”
Odpowiedź, której naprawdę chcesz: “Saldo jest poparte kompletną historią zapisów finansowych, która wyjaśnia, jak doszliśmy do kwoty 850 EUR”.”
To rozróżnienie zaczyna mieć duże znaczenie, gdy Twój produkt dodaje płatności kartą, przelewy P2P, doładowania, opłaty za wypłaty, zwroty, wstrzymania płatności, obciążenia zwrotne, obsługę wielu walut lub integrację z usługami finansowymi stron trzecich.
Firma Stripe opisuje swoją wewnętrzną księgę rachunkową jako odzwierciedlenie stanu podstawowych procesów płatniczych, wykorzystującą zasadę podwójnego zapisu do rejestrowania przepływu pieniędzy.
Nie musisz robić z każdego założyciela firmy lub menedżera produktu księgowego. Ale jeśli współpracujesz z firmą zajmującą się tworzeniem oprogramowania fintech, powinieneś znać podstawy rachunkowości, aby móc zadawać właściwe pytania architektoniczne.
Oto jak te podstawy wyglądają w praktyce.
Dlaczego księga rachunkowa ma znaczenie w rozwoju portfela cyfrowego
Cyfrowy portfel może wyglądać świetnie: przejrzysty interfejs, natychmiastowe powiadomienia push, doładowania jednym dotknięciem, przelewy, które wydają się natychmiastowe. Nic z tego nie mówi, skąd tak naprawdę pochodzi kwota na ekranie salda. To zadanie rejestru i tej części nikt nie robi zrzutów ekranu do oferty w App Store.
Dobrze zaprojektowana księga rachunkowa wykonuje mało efektowną pracę:
- Śledzi skąd pochodziły pieniądze i dokąd zostały wysłane.
- Utrzymuje stan salda klientów na poziomie zgodnym z rzeczywistym stanem rzeczy.
- Reprezentuje oczekujące transakcje i zatrzymania, nie udając, że pieniądze zostały już przelane.
- Dokładnie rejestruje opłaty, zwroty, wypłaty i korekty.
- Umożliwia badanie sporów bez konieczności ręcznego składania historii transakcji.
- Uzgadnia Twoje wewnętrzne zapisy z bankami i dostawcami usług płatniczych.
- Pozostawia ślad audytu, który nadal ma sens rok później.
Jeśli planujesz portfel cyfrowy, nie traktuj księgi głównej jako czegoś, co dodasz po premierze. To fundament finansowy, na którym opiera się wszystko inne.
Złożone przepływy płatności zazwyczaj wykorzystują systemy podwójnego zapisu, w których każda transakcja jest reprezentowana jako wpisy bilansujące. Modern Treasury, na przykład, opisuje niezmienną, skalowalną księgę rachunkową podwójnego zapisu jako standardowe podejście w przypadku, gdy firma ma do czynienia ze złożonymi lub masowymi przepływami pieniężnymi.
1. Zacznij od właściwego modelu księgi głównej
Księga rachunkowa to system zapisu opisujący ruchy finansowe w Twoim portfelu.
Zamiast tylko przechowywać:
- Saldo użytkownika A: 850 EUR
przechowujesz transakcje i wpisy, które wyjaśniają, w jaki sposób użytkownik dotarł do celu:
- Saldo początkowe: 0 EUR
Doładowanie portfela: +1000 EUR
Przelew wysłany: -100 EUR
Opłata za usługę: -10 EUR
Zakup: -40 EUR
Saldo bieżące: 850 EUR
Te ruchy to nie tylko pozycje na liście transakcji w interfejsie użytkownika. To uporządkowane zapisy finansowe.
Współczesne Ministerstwo Skarbu modeluje to za pomocą kont, transakcji księgowych i wpisów księgowych, gdzie każda transakcja zawiera co najmniej dwa wpisy.
Dzięki temu zespoły ds. rozwoju, operacji, wsparcia i finansów zyskują coś, czego nigdy nie da im zmienna liczba salda: wyjaśnienie.
Jeśli zastanawiasz się również nad tym, jak to wygląda w oczach klientów, zapoznaj się z naszym poradnikiem projektowanie historii transakcji, której użytkownicy faktycznie ufają.
2. Zrozumieć księgowość podwójną
Podwójny zapis brzmi jak żargon księgowy, ale idea, która się za tym kryje, jest prosta: każdy ruch dotyczy co najmniej dwóch kont.
Jeśli Alicja wyśle Bobowi 50 EUR, nie odejmujesz po prostu 50 EUR od Alicji i nie dodajesz osobno 50 EUR do Boba za pomocą dwóch niezależnych operacji zapisu w bazie danych. Rejestrujesz obie strony tej samej transakcji:
Portfel Alicji: -50 EUR
Portfel Boba: +50 EUR
Wpisy są równoważone.
W zależności od modelu księgowego i typów kont, są one prezentowane jako debet i kredyt. Terminologia “debet kontra kredyt” wprowadza w błąd, ponieważ jej znaczenie zmienia się w zależności od typu konta. Dlatego poproś zespół produktowy o uzgodnienie spójnych zasad, zamiast zakładać, że “debet” oznacza po prostu „wypłata”.”
Dokumenty księgowe Modern Treasury wymagają, aby każda transakcja księgowa zawierała równoważące wpisy kredytowe i debetowe, i opisują to ograniczenie jako sposób na uniknięcie sytuacji, w której pieniądze nie będą uwzględniane w oprogramowaniu.
Oto dlaczego to ograniczenie ma sens: wyobraź sobie błąd, w którym portfel pobiera 50 EUR od Alicji, ale zawiesza się przed przekazaniem środków Bobowi. Jeśli są to dwie niezależne aktualizacje, 50 EUR po prostu zniknęło z Twoich wewnętrznych rejestrów. Prawidłowo zaprojektowany model transakcji nie pozwala, aby ten niedokończony ruch stał się ważną historią finansową.
Księga rachunkowa to nie tylko księgowy drobiazg. To mechanizm kontroli produktu.
3. Oddzielenie stanu transakcji od przepływu pieniędzy
Nie każda transakcja w portfelu jest realizowana natychmiast. Płatność może znajdować się w dowolnym z poniższych stanów:
Utworzone, oczekujące, autoryzowane, utrzymywane, przetwarzane, zaksięgowane, rozliczone, nieudane, anulowane, zwrócone, cofnięte.
Dokładna terminologia zależy od dostawców i modelu portfela, jednak zasada architektoniczna obowiązuje w obu przypadkach: stan transakcji musi być jawny.
Załóżmy, że ktoś płaci 80 EUR ze swojego portfela. Dostawca może autoryzować płatność przed jej rozliczeniem. Twój system musi rozróżniać:
Zaksięgowane saldo – transakcje, które zasady Twojego rejestru uznają za sfinalizowane.
Saldo oczekujące – transakcje, które się rozpoczęły, ale jeszcze nie są sfinalizowane.
Dostępne saldo – ile klient może faktycznie wydać w tej chwili.
Te trzy liczby nie zawsze będą się zgadzać i to jest w porządku. Materiały Modern Treasury dotyczące skalowania ksiąg rachunkowych omawiają saldo zaksięgowane, oczekujące i dostępne jako oddzielne koncepcje właśnie z tego powodu.
Ma to również znaczenie dla doświadczeń klienta: nikt nie powinien być w stanie wydać 100 euro dwa razy tylko dlatego, że pierwsza transakcja o wartości 100 euro nie została jeszcze rozliczona.
4. Jak reprezentować wstrzymane transakcje
W portfelu użytkownika znajduje się 500 EUR. Użytkownik dokonuje zakupu na kwotę 120 EUR, który wymaga autoryzacji.
Zamiast od razu traktować tę kwotę 120 EUR jako wydaną, odłóż ją na później:
Saldo zaksięgowane: 500 EUR
Przytrzymaj: 120 EUR
Dostępne saldo: 380 EUR
Jeśli sprzedawca przejmie pełną kwotę 120 EUR, blokada staje się transakcją sfinalizowaną w ramach Twojego modelu księgowania. Jeśli przejmie tylko 100 EUR, ostateczna kwota transakcji wyniesie 100 EUR, a niewykorzystane 20 EUR powróci do dostępnej kwoty. Jeśli autoryzacja zostanie anulowana lub wygaśnie, zwolnij blokadę.
Dzięki temu zyskujesz bardziej przejrzysty model dla sytuacji, w których autoryzacja i rozliczenie nie następują w tym samym momencie.
Podstawowa zasada: nie należy mylić środków zarezerwowanych z dokonanym przepływem środków pieniężnych.
Założyciele czasami bagatelizują to jako szczegół implementacyjny. Ale nim nie jest. Błąd szybko prowadzi do kolejki wsparcia. Klientów nie obchodzi, czy błąd występuje w procesorze płatności, wywołaniu zwrotnym API, usłudze księgi głównej, czy transakcji w bazie danych. Widzą tylko jedno: “Moje saldo jest nieprawidłowe”.”
5. Jak przedstawić opłaty
Opłaty to kolejny aspekt, w którym proste aktualizacje salda szybko zawodzą.
Klient wysyła 100 EUR, a Twój portfel pobiera opłatę za przelew w wysokości 2 EUR. Klient traci 102 EUR; do odbiorcy dociera tylko 100 EUR. Można to przedstawić w następujący sposób:
Portfel nadawcy: -102 EUR
Portfel odbiorcy: +100 EUR
Konto opłat/przychodów: +2 EUR
Transakcja nadal podlega zasadom debetu i kredytu w księdze głównej, a także zapewnia działowi finansowemu i operacyjnemu wgląd w to, co zwykłe saldo końcowe mogłoby ukryć. Teraz mogą odpowiedzieć:
Ile przelali klienci? Ile przychodów pochodziło z opłat? Która transakcja wygenerowała daną opłatę? Czy została zwrócona? Czy rozliczenie dostawcy jest zgodne z naszymi oczekiwaniami?
Taka przejrzystość ma większe znaczenie, gdy dodasz opłaty za wypłaty, spready walutowe, opłaty za karty, opłaty za subskrypcję lub zróżnicowane ceny.
6. Jak przedstawiać zwroty pieniędzy
Częsty błąd: “naprawianie” oryginalnej transakcji podczas dokonywania zwrotu. Nie rób tego – to niszczy użyteczną historię.
Załóżmy, że klient kupił coś za 70 EUR. Pozostaw tę pierwotną płatność w księdze rachunkowej. Jeśli później otrzymają pełny zwrot pieniędzy, utwórz drugą transakcję w celu anulowania transakcji:
Oryginalny zakup: -70 EUR
Zwrot: +70 EUR
Aby uzyskać częściowy zwrot w wysokości 20 EUR:
Oryginalny zakup: -70 EUR
Częściowy zwrot: +20 EUR
Wpływ netto: -50 EUR
Teraz wiesz dokładnie, co się wydarzyło i kiedy.
Jest to związane z niezmiennością rejestru. Modern Treasury opisuje zaksięgowane transakcje w rejestrze jako zapisy mające na celu zachowanie integralności transakcji, a nie ich przepisywanie. Ta historia jest bardzo cenna, gdy sześć miesięcy później badasz sprawę pomocy technicznej, rozbieżność z dostawcą, obciążenie zwrotne lub pytanie dotyczące księgowości.
7. Nie stosuj ręcznej edycji salda jako metody regulacji
Prawdziwe systemy finansowe czasami wymagają korekt. Może dostawca zduplikował rozliczenie, błąd operacyjny spowodował zaksięgowanie środków na koncie niewłaściwego klienta, trzeba zastosować kredyt promocyjny, umorzyć opłatę, migracja spowodowała powstanie salda początkowego lub uzgodnienie wykazało rozbieżność.
Niebezpieczną wersją rozwiązania jest panel administracyjny z przyciskiem, który mówi:
Edytuj saldo: 430 EUR -> 450 EUR
Lepszą wersją jest wyraźna transakcja dostosowawcza:
Powód korekty: nieprawidłowa opłata za wypłatę
Kwota: +20 EUR
Odniesienie: sprawa pomocy technicznej #12345
Zatwierdzone przez: upoważnionego operatorar
Saldo się zmienia, ale nadal możesz wyjaśnić, dlaczego. Pytanie “Dlaczego saldo tego użytkownika wynosi 450 EUR?” zawsze powinno zawierać odpowiedź.
8. Wprowadź uzgadnianie do produktu
Twój wewnętrzny rejestr to jeden z obrazów rzeczywistości finansowej. W zależności od architektury, otrzymujesz również informacje od banków, operatorów kart płatniczych, bramek płatniczych, dostawców otwartej bankowości, partnerów ds. wypłat lub dostawców infrastruktury portfela.
W końcu te systemy muszą dojść do porozumienia. To jest pojednanie.
Modern Treasury opisuje to jako rozwiązywanie rozbieżności między saldami księgowymi a saldami raportowanymi przez bank lub zewnętrznego dostawcę. Stripe oferuje podobne narzędzia do raportowania i uzgadniania, umożliwiające śledzenie aktywności płatniczej i wypłat.
Szybki przykład: Twój system wewnętrzny oczekuje rozliczenia z dostawcą na kwotę 99 500 EUR. Dostawca zgłasza, że faktycznie rozliczono 99 470 EUR. To różnica 30 EUR i teraz ktoś musi to wyjaśnić.
Może to być uzasadniona opłata naliczona przez dostawcę. Albo zwrot, który wpłynął po upływie terminu raportowania, płatność, która nie została zrealizowana po autoryzacji, zdarzenie przetworzone dwukrotnie, powiadomienie, które nigdy nie dotarło do systemu, różnica w przeliczeniu waluty lub ręczna korekta, która nie została poprawnie zarejestrowana.
Bez uporządkowanych wpisów i odniesień w księdze rachunkowej, uzgadnianie przypomina pracę detektywa w arkuszu kalkulacyjnym. Dzięki nim można kategoryzować rozbieżności, zamiast zgadywać.
9. Nadaj każdemu zdarzeniu finansowemu możliwą do śledzenia tożsamość
Jedna decyzja, która zawsze się opłaca: zachowaj wyraźne nawiązania pomiędzy powiązanymi wydarzeniami.
W przypadku przelewu do portfela może być konieczne podłączenie wewnętrznego identyfikatora transakcji, identyfikatora transakcji w księdze głównej, identyfikatora użytkownika, identyfikatora dostawcy płatności, identyfikatora przelewu bankowego, identyfikatora zwrotu, identyfikatora oryginalnej transakcji i statusu uzgodnienia.
Dzięki temu odpowiedź na pytanie “co się stało z transakcją 48291?” można uzyskać w ciągu kilku minut, zamiast ręcznie przeszukiwać kilka baz danych. Ułatwia to również przeprowadzanie integracji w miarę rozwoju produktu.
Aby uzyskać szerszy pogląd na to, co kryje się za tymi produktami, przeczytaj nasz Przewodnik po stosie technologii Fintech.
10. Zaplanuj wydarzenia powtarzające się i nieregularne
Integracje finansowe rzadko kiedy są tak czyste, jak prośba, sukces, zrobione.
Dostawca może wysłać to samo powiadomienie więcej niż raz. Odpowiedzi docierają z opóźnieniem. Zdarzenia pojawiają się w niewłaściwej kolejności. Przekroczenie limitu czasu nie oznacza niepowodzenia płatności.
Twoja księga główna i warstwa przetwarzania transakcji wymagają jasnych reguł określających, kiedy można utworzyć nowy wpis finansowy. Jeśli Twój dostawca trzykrotnie wyśle to samo powiadomienie o pomyślnym doładowaniu, nie chcesz, aby klient został uznany trzykrotnie.
Identyfikatory, obsługa idempotentna, uzgadnianie i jawne stany to sposoby na uniknięcie sytuacji, w której powtarzające się lub opóźnione wiadomości zamieniają się w bałagan. Założyciele powinni się jednak martwić nie o termin wdrożenia, ale o wynik: to samo zdarzenie w świecie rzeczywistym nigdy nie powinno powodować dwukrotnego transferu pieniędzy.
11. Uczyń księgę rachunkową użyteczną dla operacji i wsparcia
Architektura księgi głównej nie powinna służyć tylko programistom. Narzędzia administracyjne powinny umożliwiać autoryzowanym pracownikom operacyjnym i wsparcia wgląd w bieżące saldo, dostępne saldo, oczekujące środki, aktywne wstrzymania, stan transakcji, powiązane opłaty, historię zwrotów, odniesienia zewnętrzne, stan uzgodnień oraz korekty wraz z ich przyczynami.
Nie oznacza to, że każdy agent wsparcia musi mieć przed sobą pełen model księgowości. Chodzi o to, że produkt przekłada złożoność finansową na coś, z czego człowiek może faktycznie korzystać. Solidna konstrukcja portfela uwzględnia te wewnętrzne przepływy pracy równolegle z aplikacją dla klienta, a nie po niej.
Typowe błędy w księgach rachunkowych, których należy unikać
Nawet obiecujące portfele same w sobie generują ryzyko, gdy model pieniężny rozwija się organicznie, a nie celowo. Zwróć uwagę na:
- Traktowanie zmiennego pola równowagi jako jedynego źródła prawdy.
- Aktualizacja sald nadawcy i odbiorcy poprzez operacje rozłączne.
- Traktowanie oczekujących transakcji jako zakończonych.
- Nadpisywanie pierwotnych płatności podczas przetwarzania zwrotów.
- Mieszanie środków klientów i opłat platformowych bez przejrzystych kont księgowych.
- Umożliwienie administratorom edytowania sald bez konieczności prowadzenia rejestru korekt.
- Poleganie wyłącznie na webhookach bez uzgadniania.
- Nie udało się połączyć transakcji wewnętrznych z odniesieniami zewnętrznego dostawcy.
- Finansowanie budynku i raportowanie operacyjne dopiero po uruchomieniu.
- Stosowanie niespójnych terminów dotyczących stanu transakcji w różnych systemach.
Zdefiniuj te reguły na wczesnym etapie. Portfel staje się trudniejszy do zrozumienia, gdy na jego szczycie pojawiają się kolejne funkcje.
Często zadawane pytania
Czy każdy portfel cyfrowy wymaga podwójnej księgowości?
Nie każdy prototyp potrzebuje platformy księgowej na skalę bankową. Ale gdy Twoja aplikacja rejestruje salda użytkowników lub odzwierciedla rzeczywiste ruchy finansowe, podwójne księgowanie zapewnia spójność i możliwość śledzenia, co trudno osiągnąć w inny sposób. To standard nie bez powodu: księgowania bilansowe ułatwiają rozliczanie przepływów pieniężnych.
Czy księga główna to to samo, co historia transakcji?
Nie. Historia transakcji to zazwyczaj widok aktywności widoczny dla klienta. Księga główna to podstawowy zapis finansowy służący do obliczania i wyjaśniania sald. Każda transakcja w księdze głównej może zostać zaprezentowana klientowi w różny sposób, w zależności od produktu i potrzeb UX.
Czy powinniśmy usuwać nieudane transakcje?
Prawdziwe pytanie brzmi, czy zdarzenie spowodowało zaksięgowanie w księdze finansowej. Nieudana płatność może pozostać użytecznym zapisem operacyjnym bez wpływu na ostateczne saldo księgi głównej. Twój model stanu transakcji powinien to wyraźnie rozróżniać.
Czym jest pojednanie?
Porównywanie zapisów z zapisami zewnętrznego podmiotu finansowego i badanie różnic. Nowoczesne ramy uzgadniania kont w Departamencie Skarbu obejmują rozwiązywanie luk między saldami księgowymi a raportami banku lub dostawcy.
Czy możemy dodać rejestr po uruchomieniu portfela?
Teoretycznie migrację można przeprowadzić później. W praktyce odbudowa historii finansowej po tym, jak produkt przetwarza już rzeczywiste transakcje, jest znacznie trudniejsza niż zrobienie tego poprawnie za pierwszym razem. Zdefiniuj model finansowy w trakcie projektowania architektury i odkrywania, a nie na marginesie.
Jak Appricotsoft podchodzi do rozwoju rejestru portfela
Funkcjonalność finansowa nie może po prostu wyglądać dobrze na ścieżce. Musi pozostać zrozumiała, gdy transakcja się nie powiedzie, zwrot pieniędzy pojawi się z opóźnieniem, dane dostawcy nie zgadzają się z Twoimi lub dział operacyjny musi zbadać coś nietypowego. Oto jak to osiągnąć.
Mapujemy przepływy pieniężne. Zanim zaczniemy pisać kod, sprawdzamy, gdzie wartość wchodzi, przechodzi i wychodzi z systemu – doładowania, przelewy, wypłaty, zakupy, opłaty, wstrzymania, zwroty, korekty.
Definiujemy stany transakcji. Zgadzamy się co do tego, co tak naprawdę oznaczają terminy „oczekujący”, „wysłany”, „nieudany”, „anulowany”, „cofnięty” i „zwrócony” w odniesieniu do tego konkretnego produktu, zamiast pozwolić, aby każda integracja wymyśliła własną interpretację.
Projektujemy księgę rachunkową na podstawie rzeczywistych zdarzeń związanych z produktem. Model księgowy powinien odzwierciedlać rzeczywisty portfel, a nie działać jak ogólna warstwa bazy danych dołączona później.
Od pierwszego dnia rozpoczynamy działalność operacyjną. Funkcje wsparcia, uzgadniania, przeprowadzania dochodzeń i kontroli administracyjnej są od samego początku częścią produktu – nie jest to coś, co dodamy od razu, gdy użytkownicy zaczną zgłaszać rozbieżności w saldzie.
Testujemy nieszczęśliwe ścieżki. Płatności realizowane na zasadzie „happy-path” to łatwa część kontroli jakości w fintech. Planujemy również ponowne próby, częściowe zwroty, duplikaty wiadomości, przerwane przetwarzanie i rozliczenia, które się nie pokrywają.
Dbamy o to, aby dostawa była widoczna. Dzięki naszemu Unison Framework, realizacja przebiega zgodnie z cyklem życia: „Dopasowanie”, „Plan”, „Budowa”, „Walidacja”, „Uruchomienie” i „Rozwój”, z backlogiem, kryteriami akceptacji, rejestrem ryzyka, dziennikiem decyzji, cotygodniowym statusem, notatkami demonstracyjnymi i listą kontrolną wydania jako działającymi artefaktami. Sztuczna inteligencja może pomóc w powtarzalnym wykonywaniu, scenariuszach testowych, dokumentacji i analizie – ludzie pozostają odpowiedzialni za decyzje i wyniki. Cotygodniowe demonstracje pozwalają na wczesne poznanie przepływów finansowych, zamiast pozostawiać założenia nieprzetestowane do samego końca.
Wniosek
Rejestr prawdopodobnie nigdy nie będzie funkcją, która zachęci kogoś do pobrania Twojego portfela. Nadal może być tym, co zapewni wiarygodność wszystkim innym.
Celem nie jest pokazanie prawidłowego salda na ekranie. Chodzi o możliwość wyjaśnienia, dlaczego to saldo jest prawidłowe. Księgowość podwójna zapewnia strukturę przepływów finansowych. Stany transakcji oddzielają intencje od zrealizowanych zdarzeń. Wstrzymania zapewniają uczciwość dostępnych sald. Dedykowane wpisy umożliwiają śledzenie opłat i zwrotów. Uzgadnianie zapewnia uczciwość wewnętrznych zapisów w stosunku do zewnętrznego świata finansowego.
Łącząc te decyzje, otrzymasz portfel, który jest naprawdę łatwiejszy w obsłudze, badaniu i skalowaniu – a nie tylko taki, który dobrze wygląda w wersji demonstracyjnej.
W Appricotsoft łączymy myślenie o produktach fintech, tworzenie oprogramowania na zamówienie, integrację systemów, zapewnianie jakości (QA) i transparentne wdrażanie, aby przekształcić te zasady w działające produkty. Jeśli planujesz portfel, platformę płatności lub inny produkt fintech i chcesz zdefiniować architekturę, zanim kosztowne założenia przekształcą się w kod, skontaktuj się z Appricotsoft i poproś o wycenę rozwoju.
