Какво представлява платежното съгласуване? Съпоставяне на изплатените суми от доставчици на платежни услуги към главната книга

Платежното съгласуване (reconciliation) представлява съпоставяне на действително получените суми от доставчик на платежни услуги (PSP) с това, което вашите клиенти реално са ви дължали. Това е различен проблем от банковото съгласуване и е по-сложен, тъй като едно плащане от PSP никога не представлява едно плащане за една фактура.

Основният симптом: продали сте стоки или услуги за 10 000 €, а в банковата ви сметка са постъпили 9 712,40 €. И двете числа са верни. Всичко по средата е това, което това съгласуване обяснява.

Защо изплатената сума никога не съвпада с продажбите

Еднократно изплащане от Stripe, Adyen или PayPal представлява нетен пакет (net batch). В периода между плащането от клиента и постъпването на парите в сметката, PSP е направил следното:

• агрегирал е много плащания за даден отчетен период,
• удържал е своите такси за всяка транзакция,
• удържал е възстановени суми (refunds) и оспорвани плащания (chargebacks), възникнали в същия прозорец,
• евентуално е задържал сума като гаранционен резерв (reserve),
• и е превел остатъка дни по-късно в един общ превод.

Така извлечението от банката показва един ред - 9 712,40 € - докато в главната книга има десетки фактури, нито една от които не отговаря на тази сума. Директното съпоставяне на плащането с фактурите е невъзможно; изплатената сума първо трябва да бъде разложена.

Разлагане на плащането

Пакетът от плащания се разпада на категории, като всяка категория има различно значение за главната книга:

Категория	Какво представлява	Ефект върху главната книга
Таксувания (Charges)	Плащания от клиенти	Погасява вземания
Възстановявания (Refunds)	Суми, върнати на клиенти	Сторнира погасено вземане
Такси (Fees)	Комисиона на PSP	Разход
Оспорвани плащания (Chargebacks)	Оспорени плащания, държани обратно	Възстановява вземане, плюс такса
Корекции / резерви (Adjustments / reserves)	Временни задържания и рискови задържания	Салдо, дължимо от PSP

Равенството, което задължително трябва да е в сила:

Брутни таксувания − възстановявания − такси − оспорвани плащания ± корекции = Нетно плащане

Ако то не излиза, пакетът е импортиран непълно – и тази проверка е по-ценна от всяко индивидуално съпоставяне, защото доказва, че нищо не е било пропуснато безшумно.

Счетоводни статии

Контирането на пакет от плащания с брутни постъпления 10 000 €, такси 250 € и възстановявания 37,60 € изглежда по следния начин:

Сметка	Дебит	Кредит
2710 Банка	9 712,40
6800 Финансови разходи (такси към PSP)	250,00
5000 Приходи / сторниране на вземания (възстановявания)	37,60
2410 Вземания от клиенти		10 000,00

Тълкуванието е следното: задълженията на клиентите в размер на 10 000 € се погасяват, PSP е задържал 250 €, 37,60 € са върнати на клиентите, а 9 712,40 € са постъпили в банката. Таксата е реален разход, който никога не се появява в нито една клиентска фактура – което е точно причината брутните приходи и банковите депозити да се разминават и защо съгласуването само по банковия ред безшумно подценява както приходите, така и разходите.

За платформи тип прекѝветите (marketplace) има още едно ниво. Ако изплащането включва пари, принадлежащи на търговци, приходите на самата платформа са само нейната комисиона; остатъкът е задължение. Правилата за контиране на Nordlet обхващат това с предварително зададени ключове – settlements.fees, settlements.commissionRevenue, settlements.sellerPayable и settlements.suspense – така че едно разделено плащане да отчете комисионата като приход, а дялът на търговеца като задължение, вместо изкуствено да надува приходите на платформата.

Как го прави Nordlet

Работният процес се състои от три крайни точки (endpoints):

1. Импортиране. POST /v1/bank/settlements/import прочита отчет за съгласуване на плащания от Stripe и създава пакет от плащания (доставчик, ID на плащане, валута, брутна сума, такси и нетно) с по един ред за всяка подлежаща транзакция, като всяка носи своята категория. Пакетите са уникални за съответния доставчик и ID на плащане, така че повторното импортиране на същия отчет не може да доведе до двойно отчитане.
2. Съпоставяне. POST /v1/bank/settlements/match свързва редовете с таксувания и възстановявания към фактурите за продажба, към които принадлежат. Редовете носят статус на съпоставяне unmatched (неразпределени), matched (разрешени автоматично от поръчката или референцията към фактурата в отчета) или manual (решено ръчно от оператор). Редовете за такси и корекции съзнателно не подлежат на съпоставяне с фактури – опитът за това се отхвърля, вместо да се правят предположения.
3. Контиране. POST /v1/bank/settlements/post записва счетоводните статии за целия пакет чрез горепосочените правила за контиране и променя статуса на пакета от imported (импортиран) в posted (контиран). Несъпоставените постъпления попадат в сметка за извънредни/неизяснени суми (suspense account), вместо да бъдат насилствено обвързани към фактура – те са видими и умишлено предизвикват дискомфорт, докато не бъдат разрешени.

Плащане във валута, различна от основната валута на компанията, се контира без нужда от ръчна намеса. Журналът се записва в основната валута: пакетът се преизчислява по курса за датата на контиране, вземанията се отписват по курса, при който е била издадена всяка фактура, а разликата между двата курса се отчита като реализирана валутна печалба или загуба. Единственият случай, който все още се отхвърля, е еднократно плащане, чиито редове смесват няколко валути.

Контираният пакет е обвързан с входящия ред от банковото извлечение в реалната банкова сметка. В менюто Bank → Match (Банка → Правила за съпоставяне) описвате как едно плащане се появява във вашето извлечение: текста, който редът винаги съдържа, и по избор – префикса на ID-то на плащането в него. Когато дадено извлечение бъде импортирано, редът, който отговаря на дадено правило, се закача към съответния пакет по ID на плащането или чрез съпоставяне на брутното/нетното салдо на пакета в рамките на зададен от вас времеви прозорец. Тогава банковият ред носи счетоводната статия на плащането, вместо да чака втори, дублиращ се запис, а функциите POST /v1/bank/settlements/link и /unlink задават или коригират връзката ръчно.

Добри практики

• Съгласувайте по плащания, а не по месеци. Плащането е естествената единица; агрегирането на едномесечни плащания преди съгласуване унищожава проверката на равенството, която прави грешките лесни за откриване.
• Никога не контирайте нетната сума като приход. Това е най-често срещаната грешка в счетоводството на платформите: отчитането на 9 712,40 € като приход подценява както продажбите, така и разходите, изкривява брутния марж и обикновено води до грешки в ДДС – тъй като ДДС се дължи върху брутната сума, платена от клиента, а не върху това, което PSP е превел.
• Внимавайте с времевото разминаване. Плащане, получено на 30 юни и изплатено на 3 юли, принадлежи към приходите за юни и паричните потоци за юли. В края на периода разликата стои като вземане от PSP – реални пари, намиращи се в чужда сметка.
• Съгласувайте възстановяванията с първоначалната продажба. Едно възстановяване, което не е свързано обратно, оставя платената фактура да изглежда платена, а приходите – надценени.

FAQ

Каква е разликата между платежното съгласуване и банковото съгласуване?

Банковото съгласуване сравнява вашата главна книга с банковото извлечение, ред по ред. Платежното съгласуване се намира едно ниво по-рано: то разглобява еднократно плащане от PSP на множеството таксувания, възстановявания и такси зад него, така че тези банкови редове изобщо да могат да бъдат обяснени.

Защо изплатената сума от Stripe не съвпада с моите продажби?

Защото едно плащане е нетен пакет: брутни таксувания минус такси, възстановявания, оспорвани плащания и евентуален резерв, изплатени по графика на PSP, а не според датата на фактурата. Всеки един от тези компоненти трябва да бъде от отчетен отделно, за да могат двете суми да се съгласуват.

Трябва ли таксите на PSP да се приспадат директно от приходите (netting)?

Не. Приходът е брутната сума, платена от клиента; таксата на PSP е разход за нейното събиране. Приспадането им една от друга подценява както приходите, така и разходите, изкривява маржовете и обикновено води до грешно третиране по ЗДДС.

Как се обработват разпределенията при платформите тип прекѝветите (marketplace)?

Приходите на платформата са нейният комисионен доход; делът на търговеца е задължение, докато не бъде изплатен. Отчитането на цялата сума на плащането като приход на платформата огромно надценява нейните приходи – отделните правила за контиране на комисионни приходи и задължения към търговци съществуват точно за да ги държат разделени.

Какво се случва с несъпоставените редове от плащанията?

Те се контират в сметка за неизяснени суми (suspense account), вместо да бъдат насилствено обвързани към фактура. Това поддържа главната книга балансирана, а проблемът – видим; салдото по тази сметка представлява списък със задачи за изпълнение и трябва да бъде нула преди приключване на периода.