Mis on maksete täpsustamine? Väljamaksete sidumine pearaamatuga
Miks Stripe'i väljamakse ei võrdu kunagi teie arvetega, kuidas jagada laekumine müügiks, tasudeks ja tagastusteks ning kuidas pearaamatu kanded tegelikult toimivad.
Maksete täpsustamine (payment reconciliation) on protsess, kus makseteenuse pakkuja (PSP) tegelikult välja makstud summa seotakse sellega, mida kliendid teile tegelikult võlgnesid. See on pangakonto täpsustamisest (bank reconciliation) erinev ja keerulisem ülesanne, sest PSP väljamakse ei koosne peaaegu kunagi ühest maksest ühe arve eest.
Tüüpiline ilming: te tegite müüke 10 000 € eest ja pangale laekus 9 712,40 €. Mõlemad numbrid on õiged. Kõik nende vahele jääv ongi see, mida see täpsustamisjuhend selgitab.
Miks väljamakse ei vasta müügile
Üksik Stripe'i, Adyeni või PayPali väljamakse on netosummade koondkannete kogum (net batch). Ajavahemikus kliendi tehtud maksest kuni raha kohalejõudmiseni on PSP:
- koondanud mitu makset arveldusperioodi jooksul,
- arvestanud maha tehingupõhised tasud,
- arvestanud maha samas ajavahemikus toimunud tagastused ja tagasinõuded (chargeback),
- võib-olla kinni pidanud tagatise (reserve),
- ja maksnud ülejäägi päevi hiljem üheainsa ülekandega.
Seega näitab väljavõte ühte rida – 9 712,40 € –, samas kui pearaamatus on kümneid arveid, millest ükski ei vasta sellele summale. Väljamakse otsene sidumine arvetega on võimatu, mistõttu tuleb väljamakse kõigepealt komponentideks lammutada.
Komponentideks lammutamine
Arvelduskogum jaguneb kategooriatesse ja iga kategooria tähendab pearaamatu jaoks midagi muud:
| Kategooria | Mis see on | Mõju pearaamatule |
|---|---|---|
| Laekumised (Charges) | Kliendi maksed | Kustutab nõuded |
| Tagastused (Refunds) | Kliendile tagastatud raha | Tühistab tasutud nõude |
| Tasud (Fees) | PSP vahendustasu | Kulu |
| Tagasinõuded (Chargebacks) | Vaidlusalused maksed, mis on tagasi võetud | Avab nõude uuesti, lisandub tasu |
| Korrigeerimised / reservid | Ajastuse ja riskiga seotud kinnipidamised | PSP-i ees olev kohustus |
Seos, mis peab alati kehtima:
Brutolaekumised − tagastused − tasud − tagasinõuded ± korrigeerimised = Netoväljamakse
Kui see ei klapi, on kogum imporditud puudulikult. See kontroll on väärtuslikum kui ükski üksik vaste, sest see tõestab, et midagi ei jäänud märkamatult vahele.
Kanded
10 000 € suuruse bruttolaekumise, 250 € suuruste tasude ja 37,60 € suuruste tagastustega arvelduskogumi kajastamine:
| Kontot | Deebet | Kreedit |
|---|---|---|
| 2710 Pank | 9 712,40 | |
| 6800 Finantskulud (PSP tasud) | 250,00 | |
| 5000 Müügitulu / nõuete tühistamine (tagastused) | 37,60 | |
| 2410 Nõuded ostjate vastu | 10 000,00 |
Seda tõlgendatakse nii: klientide 10 000 € suurused võlad on kustutatud, PSP jatis endale 250 €, 37,60 € läks klientidele tagasi ja 9 712,40 € jõudis panka. Tasu on reaalne kulu, mis ei ilmu ühelgi kliendi arvel – just seetõttu lahknevad brutotulu ja pangalaekumised ning miks ainult pangaandmete alusel täpsustamine alahindab vaikimisi nii tulusid kui ka kulusid.
Platvormide (marketplaces) puhul on veel üks kiht. Kui väljamakse sisaldab müüjatele kuuluvat raha, on platvormi tulu ainult tema vahendustasu; ülejääk on kohustus. Nordlet'i kontoreeglid katavad selle spetsiaalsete võtmete abil – settlements.fees, settlements.commissionRevenue, settlements.sellerPayable ja settlements.suspense –, nii et jagatud väljamakse kannab vahendustasu tuludesse ja müüja osa kohustustesse, selle asemel et platvormi tulusid kunstlikult paisutada.
Kuidas Nordlet seda teeb
Töövoog koosneb kolmest otspunktist:
- Import.
POST /v1/bank/settlements/importloeb Stripe'i väljamaksete täpsustusaruande ja loob arvelduskogumi – teenusepakkuja, väljamakse ID, valuuta, brutosumma, tasud ja netosumma –, kus iga alustehingu kohta on üks rida koos selle kategooriaga. Kogumid on teenusepakkuja ja väljamakse ID lõikes unikaalsed, nii et sama aruande uuesti importimine ei saa seda topelt arvestada. - Sidumine.
POST /v1/bank/settlements/matchseob laekumise ja tagastuse read müügiarvetega, mille juurde need kuuluvad. Ridadel on vastavuse olekunmatched(sidumata),matched(seotud automaatselt aruandes olevate tellimuse- või arvenumbrite alusel) võimanual(inimeste poolt otsustatud). Tasude ja korrigeerimise ridu ei ole ette nähtud arvetega siduda – katse seda teha lükatakse tagasi, selle asemel et oletada. - Kandesse kanda.
POST /v1/bank/settlements/postkirjutab kogu kogumi pearaamatu kanded ülaltoodud kontoreeglite kaudu ja muudab kogumi olekuimported-st (imporditud) olekuksposted(kantu). Sidumata laekumised suunatakse oote- ehk vahekontole, selle asemel et neid jõuga arvele suruda – need on nähtavad ja teadlikult ebamugavad, kuni need lahendatakse.
Ettevõtte baasvaluutast erinevas valuutas olev väljamakse kantakse sisse ilma käsitsi sekkumiseta. Kanne koostatakse baasvaluutas: kogum konverteeritakse selle kande kuupäeva kursiga, nõuded suletakse iga arve väljastamise kuupäeva kursiga ning kahe kursuse vaheline jääk kajastatakse realiseeritud kursikasumi või -kahjumina. Ainus juhtum, mis endiselt tagasi lükatakse, on üks väljamakse, mille read segavad mitut valuutat.
Kantu kogum seotakse tegelikul pangakontol oleva sissetuleva panga väljavõtte reaga. Pank → Match reeglite all kirjeldatakse, kuidas väljamakse teie väljavõttel kuvatakse: tekst, mida rida alati sisaldab, ja soovi korral selle sees oleva väljamakse ID eesliide. Väljavõtte importimisel seotakse reeglile vastav rida oma kogumiga väljamakse ID järgi või sobitades kogumi netosummat teie määratud kuupäevavahemikus. Seejärel kannab pangarida arvelduskande ootamata teist, duplikaatkannet ning POST /v1/bank/settlements/link ja /unlink määravad või parandavad seose käsitsi.
Parimad praktikat
- Täpsustage väljamakse, mitte kuu kaupa. Väljamakse on loomulik ühik; terve kuu väljamaksete koondamine enne täpsustamist hävitab kontrolli, mis aitab vigu leida.
- Ärge kunagi kandke netosummat tuluna. See on platvormi raamatupidamises kõige levinum viga: 9 712,40 € suuruse tulu kajastamine alahindab nii müüki kui ka kulusid, moonutab brutomarginaali ja tavaliselt alahindab ka käibemaksu – sest käibemaks tuleb brutolt, mille klient maksis, mitte sellelt, mille PSP edastas.
- Jälgige ajalist nihet. 30. juunil tehtud ja 3. juulil välja makstud makse kuulub juuni tulu ja juuli raha hulka. Perioodi lõpus seisab vahe PSP-lt saadava nõudena – see on reaalne raha kellegi teise kontol.
- Täpsustage tagastused algse müügiga. Sidumata tagastus jätab tasutud arve mulje, et see on makstud, ja tulu on üle hinnatud.
FAQ
Mis vahe on maksete täpsustamisel ja panga täpsustamisel?
Panga täpsustamine võrdleb teie pearaamatut pangaväljavõttega rida-realt. Maksete täpsustamine toimub ühe astme võrra varem: see jagab ühe PSP väljamakse paljudeks selle taga olevateks laekumisteks, tagastusteks ja tasudeks, et neid pangaridu üldse saaks selgitada.
Miks minu Stripe'i väljamakse ei vasta minu müügile?
Kuna väljamakse on netosummade kogum: brutolaekumised, miinus tasud, tagastused, tagasinõuded ja võimalik reserv, mis makstakse välja PSP graafiku, mitte arve järgi. Kõik need komponendid tuleb eraldi arvesse võtta, et need kaks summat klappima saada.
Kas PSP tasud tuleks tuludest maha arvata?
Ei. Tulu on brutisumma, mille klient maksis; PSP tasu on selle sissenõudmise kulu. Nende netomahtudes kajastamine alahindab nii tulusid kui ka kulusid, moonutab marginaale ja käsitleb käibemaksu üldiselt valesti.
Kuidas käsitletakse platvormi (marketplace) jaotusi?
Platvormi tulu on selle vahendustasu; müüja osa on kohustus, kuni see välja makstakse. Kogu väljamakse kajastamine tuluna suurendab platvormi tulu kunstlikult – vahendustasu tulu ja müüja kohustuse jaoks on olemas eraldi kontoreeglid just selleks, et neid lahus hoida.
Mis juhtub sidumata arveldusridadega?
Need kantakse oote- ehk vahekontole, selle asemel et neid sunniviisiliselt arvega siduda. See hoiab pearaamatu tasakaalus ja probleemi nähtaval; vahekonto saldo on töönimekiri ja see peaks enne perioodi sulgemist olema tühine.