Kas yra mokėjimų derinimas? Mokėjimo paslaugų teikėjų išmokų susiejimas su didžiąja knyga

Mokėjimų derinimas (payment reconciliation) – tai faktiškai mokėjimo paslaugų teikėjo (PSP) išmokėtos sumos susiejimas su ta suma, kurią jums iš tikrųjų buvo skolingi klientai. Tai kitokia ir sudėtingesnė problema nei banko sąskaitų derinimas, nes PSP išmoka (payout) niekada nebūna tiesiog vienas mokėjimas už vieną sąskaitą faktūrą.

Pagrindinis požymis: pardavėte už 10,000 €, o į banką įkrito 9,712.40 €. Abu skaičiai yra teisingi. Viskas, kas yra tarp jų, ir yra tai, ką paaiškina šis derinimas.

Kodėl išmoka niekada nesutampa su pardavimais

Viena Stripe, Adyen ar PayPal išmoka yra grynųjų operacijų suvestinė (net batch). Nuo to momento, kai klientas sumoka, iki tol, kol pinigai pasiekia jūsų sąskaitą, PSP:

• agregavo daugybę įmokų per atsiskaitymo laikotarpį,
• išskaičiavo savo komisinius mokesčius už kiekvieną operaciją,
• išskaičiavo grąžinimus (refunds) ir mokėjimų atšaukimus (chargebacks), atliktus per tą patį laikotarpį,
• galbūt sulaikė lėšas kaip rezervą,
• ir pervedė likutį po kelių dienų vienu pavedimu.

Taigi banko išraše matoma viena eilutė – 9,712.40 € – tuo tarpu didžiojoje knygoje yra dešimtys sąskaitų faktūrų ir nė viena iš jų nesutampa su šia suma. Tiesiogiai susieti išmokos su sąskaitomis faktūromis neįmanoma; pirmiausia išmoką reikia išskaidyti.

Išskaidymas

Atsiskaitymų suvestinė išskaidoma į kategorijas, ir kiekviena kategorija didžiajai knygai reiškia vis ką kita:

Kategorija	Kas tai yra	Poveikis didžiajai knygai
Įmokos	Klientų mokėjimai	Sudengia gautinas sumas
Grąžinimai	Klientams grąžinti pinigai	Atšaukia (stornuoja) sudengtą gautiną sumą
Mokesčiai	PSP komisiniai	Sąnaudos
Mokėjimų atšaukimai	Ginčijami mokėjimai, kurie buvo atšaukti	Atkuria gautiną sumą ir priskaičiuoja mokestį
Koregavimai / rezervai	Sulaikytos sumos dėl laiko skirtumų ir rizikos	PSP skola jums (gautina suma)

Lygybė, kuri privalo galioti:

Gross charges − refunds − fees − chargebacks ± adjustments = Net payout

Jei ji nesutampa, vadinasi, suvestinė buvo importuota ne visa – ir šis patikrinimas yra vertingesnis už bet kokį pavienį susiejimą, nes jis įrodo, kad jokia informacija nebuvo tyliai prarasta.

Įrašai

Registruojant atsiskaitymų suvestinę, kurioje yra 10,000 € bruto įmokų, 250 € mokesčių ir 37.60 € grąžinimų:

Sąskaita	Debetas	Kreditas
2710 Bankas	9,712.40
6800 Finansinės ir investicinės veiklos sąnaudos (PSP mokesčiai)	250.00
5000 Pardavimo pajamos / gautinų sumų atšaukimas (grąžinimai)	37.60
2410 Pirkėjų įsiskolinimai		10,000.00

Skaitykite tai taip: 10,000 € klientų skolos yra sudengiamos, PSP pasiliko 250 €, 37.60 € buvo grąžinta klientams, o 9,712.40 € pasiekė banką. Mokestis yra realios sąnaudos, kurios niekada neatsispindi jokioje kliento sąskaitoje faktūroje – būtent todėl bruto pajamos ir banko įplaukos skiriasi, ir dėl to derinant vien pagal banko eilutę tyliai sumažinamos tiek pajamos, tiek sąnaudos.

Prekyvietėms (marketplaces) egzistuoja dar vienas lygmuo. Jei į išmoką įeina pardavėjams priklausantys pinigai, platformos pajamos yra tik jos komisiniai; visa kita yra įsipareigojimas. Nordlet registravimo taisyklės tai išsprendžia naudodamos specialius raktus – settlements.fees, settlements.commissionRevenue, settlements.sellerPayable ir settlements.suspense – todėl išskaidyta išmoka komisinius užregistruoja kaip pajamas, o pardavėjo dalį – kaip mokėtiną sumą, užuot dirbtinai išpūtus platformos pajamas.

Kaip tai daro Nordlet

Procesą sudaro trys galiniai punktai (endpoints):

1. Importas. POST /v1/bank/settlements/import nuskaito Stripe išmokų derinimo ataskaitą ir sukuria atsiskaitymų suvestinę – teikėjas, išmokos ID, valiuta, bruto suma, mokesčiai ir grynasis likutis – su viena eilute kiekvienai pamatinei operacijai ir nurodyta jos kategorija. Suvestinės yra unikalios pagal teikėją ir išmokos ID, todėl iš naujo importavus tą pačią ataskaitą, dubliavimas neįmanomas.
2. Susiejimas (Match). POST /v1/bank/settlements/match susieja įmokų ir grąžinimų eilutes su joms priklausančiomis pardavimo sąskaitomis faktūromis. Eilutės turi susiejimo būseną: unmatched, matched (išspręsta automatiškai pagal ataskaitoje esančią užsakymo ar sąskaitos faktūros nuorodą) arba manual (nusprendė žmogus). Mokesčių ir koregavimų eilutės iš principo nesiejamos su sąskaitomis faktūromis – tokie bandymai atmetami, užuot spėliojus.
3. Registravimas (Post). POST /v1/bank/settlements/post sukuria didžiosios knygos įrašus visai suvestinei pagal aukščiau pateiktas registravimo taisykles ir pakeičia suvestinės būseną iš imported į posted. Nesusietos įplaukos patenka į neaiškių sumų sąskaitą (suspense account), užuot buvusios prievarta priskirtos sąskaitai faktūrai – ten jos lieka matomos ir specialiai kelia nepatogumą tol, kol yra išsprendžiamos.

Verta paminėti du apribojimus. Šiuo metu atsiskaitymai tvarkomi bazinėje įmonės valiutoje, todėl užsienio valiutos išmokoms reikalingas rankinis apdorojimas. Be to, suvestinė registruojama kaip visuma, o ne susiejama su konkrečia įeinančia banko išrašo eilute realioje banko sąskaitoje – pastarosios derinamos pagal sumą ir datą, bet nesusiejamos automatiškai.

Kaip tai atlikti teisingai

• Derinkite pagal išmoką, o ne pagal mėnesį. Išmoka yra natūralus atskaitos vienetas; apjungus viso mėnesio išmokas prieš derinant, prarandamas lygybės patikrinimas, kuris padeda aptikti klaidas.
• Niekada neregistruokite grynosios sumos kaip pajamų. Tai pati dažniausia klaida platformų apskaitoje: užregistravus 9,712.40 € kaip pajamas, dirbtinai sumažinami tiek pardavimai, tiek sąnaudos, iškraipoma bendrojo pelno marža ir dažniausiai apskaičiuojamas per mažas PVM – nes PVM turi būti skaičiuojamas nuo bruto sumos, kurią sumokėjo klientas, o ne nuo tos, kurią pervedė PSP.
• Stebėkite laiko skirtumus. Mokėjimas, priimtas birželio 30 d. ir išmokėtas liepos 3 d., priklauso birželio pajamoms ir liepos pinigų srautams. Laikotarpio pabaigoje šis skirtumas apskaitomas kaip gautina suma iš PSP – realūs pinigai kažkieno kito sąskaitoje.
• Susiekite grąžinimus su pirminiu pardavimu. Atgal nesusietas grąžinimas palieka sudengtą sąskaitą faktūrą atrodančią apmokėta, o pajamas – dirbtinai padidintas.

D.U.K.

Kuo skiriasi mokėjimų derinimas nuo banko sąskaitų derinimo?

Banko sąskaitų derinimas lygina jūsų didžiąją knygą su banko išrašu eilutė po eilutės. Mokėjimų derinimas yra vienu lygiu anksčiau: jis išskaido vieną PSP išmoką į daugybę už jos slypinčių įmokų, grąžinimų ir mokesčių, kad tas banko eilutes apskritai būtų galima paaiškinti.

Kodėl mano Stripe išmoka nesutampa su pardavimais?

Nes išmoka yra grynųjų operacijų suvestinė: bruto įmokos atėmus mokesčius, grąžinimus, mokėjimų atšaukimus ir bet kokius rezervus, kurios sudengiamos pagal PSP grafiką, o ne pagal sąskaitos faktūros terminus. Kad šie du skaičiai sutaptų, kiekvienas iš minėtų komponentų turi būti apskaitytas atskirai.

Ar PSP mokesčiai turėtų būti sudengiami su pajamomis?

Ne. Pajamos yra bruto suma, kurią sumokėjo klientas; PSP mokestis yra šių pinigų surinkimo sąnaudos. Jų sudengimas neįvertina tiek pajamų, tiek sąnaudų, iškraipo maržas ir dažniausiai lemia neteisingą PVM apskaičiavimą.

Kaip tvarkomi prekyviečių lėšų padalijimai?

Platformos pajamos yra jos komisiniai; pardavėjo dalis yra įsipareigojimas, kol ji nėra išmokama. Užregistravus visą išmoką kaip pajamas, platformos pajamos būtų smarkiai išpūstos – atskiros registravimo taisyklės komisinių pajamoms ir mokėtinoms sumoms pardavėjui egzistuoja būtent tam, kad jos būtų atskirtos.

Kas nutinka nesusietoms atsiskaitymų eilutėms?

Jos užregistruojamos neaiškių sumų sąskaitoje (suspense account), užuot buvusios prievarta priskirtos sąskaitai faktūrai. Tai išlaiko didžiosios knygos balansą, o problema išlieka matoma; neaiškių sumų sąskaitos likutis yra tarsi nebaigtų darbų sąrašas, ir jis turėtų būti tuščias prieš uždarant laikotarpį.