Як побудувати базу контрагентів з рахунків KSeF і не втратити дані клієнтів

Рахунки KSeF можуть стати добрим джерелом даних про контрагентів, якщо компанія сприймає їх як структурований потік інформації, а не як автоматичну CRM. З бізнес-рахунків зазвичай можна взяти NIP, назву, адресу, роль сторони, номери документів, дати та історію операцій.

Найважливішим робочим ідентифікатором для польських компаній часто є NIP, але картка контрагента не повинна закінчуватися лише податковим номером. Практична картка також показує, чи це клієнт, постачальник, отримувач коригувань, разовий контрагент або компанія для додаткової перевірки.

У KSeFGPT модуль Контрагенти може допомагати підтримувати такий порядок під час щоденної роботи з рахунками: через заповнення даних за NIP, імпорт з Excel або CSV, ручне додавання і додавання покупця з рахунку, якщо його ще немає в базі.

KSeF не створює базу клієнтів за компанію, але структурований рахунок містить дані сторін документа. Це практична відправна точка для бази покупців і постачальників.

Найбільша помилка - безконтекстно додавати кожну сторону з рахунку як повноцінного клієнта. Спочатку треба визначити роль контрагента, якість даних і те, чи сам рахунок не потребує з'ясування.

Найкраща база контрагентів росте під час звичайної роботи: імпорту рахунків, виставлення документів, отримання вхідних рахунків і впорядкування історії операцій.

Міністерство фінансів Польщі описує структурований рахунок як XML-документ, сумісний з логічною структурою FA(3). Ця структура охоплює, зокрема, сторони рахунку, детальні дані документа, суми, ставки податку, платіжну інформацію та додаткові елементи.

Для бази контрагентів найважливіші дані сторін: продавець, покупець і можливі додаткові суб'єкти. Вони допомагають зрозуміти, з ким компанія працює, хто виставляє їй рахунки, кому вона виставляє документи і які відносини повторюються.

Поля ідентифікації варто відокремити від історії операцій. NIP, назва й адреса описують контрагента тоді, коли вони доступні й коректні для конкретного рахунку. Номер рахунку, номер KSeF, дата і суми описують конкретну подію.

У щоденній мові компанії часто говорять про базу клієнтів, але з погляду рахунків KSeF точніше говорити про базу контрагентів. Вихідні рахунки показують покупців, тобто зазвичай клієнтів. Вхідні рахунки показують продавців, тобто зазвичай постачальників, якщо документ справді стосується покупки компанії.

Такий поділ не завжди постійний. Компанія, якій ви сьогодні продаєте послугу, завтра може виставити вам рахунок як субпідрядник. Якщо система створить два окремі записи, звіти й історія співпраці швидко розійдуться.

Тому краще мати один запис контрагента і кілька ролей або відносин. Запис описує суб'єкт. Ролі описують, як цей суб'єкт з'являється в обігу рахунків.

Найпростіший процес починається з імпорту або синхронізації рахунків. На старті не потрібна повна CRM. Спочатку достатньо зібрати сторони з рахунків, розпізнати NIP польських компаній, об'єднати повторювані записи і позначити ролі.

Другий етап - очищення даних. Перевірте, чи одна компанія не має кількох назв, чи адреса не застаріла, чи імпортований запис не дублює ручний, і чи в списку немає сторін з рахунків, які потребують з'ясування.

Лише третій етап - збагачення бази операційними даними: власник відносин, бажаний термін оплати, номер клієнта в ERP, категорія постачальника, бухгалтерські нотатки або внутрішні позначки для експорту.

Мінімальна база контрагентів не мусить бути довгою. Вона має бути однозначною. Спочатку потрібна ідентифікація суб'єкта, потім контактні або адресні дані, а вже потім поля для бухгалтерії, продажів і експорту.

Не всі поля мають походити з рахунку. Номер KSeF, дата і сума будують історію операцій. Контактна особа, менеджер, сегмент або нотатка про умови співпраці зазвичай походять з роботи команди, а не з XML.

Добре спроєктована база також показує джерело даних. Інформацію з рахунку, ручну нотатку і дані з реєстру за NIP варто трактувати по-різному.

Перша проблема - дублікати. Та сама компанія може бути в старій таблиці, імпорті з Excel, вхідному рахунку і ручному записі. Якщо система не об'єднує обережно, команда починає вибирати контрагента навмання.

Друга проблема - сліпа довіра до одного рахунку. У рахунку може бути описка, стара адреса або дані, введені продавцем поспіхом. Добра база не лише зберігає дані, а й показує, коли запис треба перевірити.

Третя проблема - змішування продажів і бухгалтерського контексту. Не кожна сторона з рахунку закупівлі є потенційним клієнтом. Іноді це разовий постачальник, оператор платежів, технічна сторона або рахунок, який компанія взагалі не повинна обліковувати.

KSeF означає, що рахунок може з'явитися на NIP компанії без окремого листа від продавця. У нормальному обігу це корисно, але невідомий продавець потребує дисципліни. Такий суб'єкт не повинен автоматично потрапляти в базу як звичайний активний контрагент.

Спочатку перевірте, чи покупка була реальною: замовлення, договір, корпоративна картка, працівник, філія, проєкт і номер KSeF. Якщо документ схожий на помилку або зловживання, перейдіть до процедури з тексту Що робити, якщо в KSeF з'явився рахунок за не наші покупки?.

Такий суб'єкт можна залишити як технічний запис до з'ясування, але не варто змішувати його зі звичайними клієнтами. Так звіти продажів, список постачальників і історія оплат залишаються зрозумілими.

У модулі Контрагенти KSeFGPT база покупців і постачальників задумана як частина роботи з рахунками, а не окремий каталог, який треба вести вручну з нуля. Дані компанії можна заповнювати за NIP з GUS, імпортувати з Excel або CSV, додавати вручну або дописувати під час роботи з рахунком.

Практична користь проста: база може рости тоді, коли користувач і так імпортує або виставляє документи. Якщо покупця ще немає в картотеці, застосунок може додати його під час роботи з рахунком.

Рішення все одно залишається за компанією. KSeFGPT допомагає зменшувати кількість описок і дублікатів, але не повинен замінювати рішення, чи суб'єкт є клієнтом, постачальником, технічним записом або справою до з'ясування.

База контрагентів з рахунків не повинна існувати лише для того, щоб надсилати більше пропозицій. Її перше завдання простіше і важливіше: коректні дані для рахунків, менше дублікатів, швидший пошук документів, кращий контроль оплат і менше помилок в експорті до бухгалтерії.

Лише на другому рівні така база може підтримувати продажі: активні клієнти, перерви в покупках, повторні покупці або компанії, де зростає сума операцій. Якщо почати з аналітики продажів без порядку в даних, звіти виглядатимуть професійно, але спиратимуться на слабку основу.

Добрий процес починається з питань: чи запис коректний, чи пов'язаний з правильним NIP, чи має правильну роль, чи рахунки реальні і чи історія операцій не змішує кілька суб'єктів в одному місці.

Коли база чиста, можна вимірювати речі, які справді допомагають компанії. Не йдеться лише про кількість контрагентів. Важливіші активність, повторюваність операцій, суми рахунків, терміни оплати, частота коригувань і частка рахунків до з'ясування.

Корисні і вихідні, і вхідні рахунки. Вихідні показують клієнтів і доходи. Вхідні показують постачальників, витрати і операційні ризики. Разом вони дають повнішу картину бізнес-відносин.

Для теми дат і розрахунків прочитайте Термін оплати рахунку в KSeF. Для регулярного отримання рахунків допоможе Як отримати рахунок з KSeF крок за кроком.

Якщо хочете будувати базу контрагентів з KSeF, почніть з процесу отримання документів. Посібник Як отримати рахунок з KSeF крок за кроком пояснює, чому вхідні рахунки треба сприймати як постійну скриньку документів.

Для невідомих продавців прочитайте Що робити, якщо в KSeF з'явився рахунок за не наші покупки?. Для дат, оплат і історії операцій корисний текст Термін оплати рахунку в KSeF.

Для ширшого контексту продукту перегляньте KSeFGPT - застосунок для імпорту, експорту та AI-аналітики рахунків.