Рахунок від постачальника потрапляє на ваш стіл. Товар може вже бути на складі, а послуга надана, проте час на оплату починає спливати миттєво. Отже, що насправді відбувається до того, як гроші покидають компанію? Вітаємо у черговій порції знань від М365FM. Я Мір Пітерс, і сьогодні ми розглядаємо кредиторську заборгованість у Dynamics 365 простою мовою. Це не просто місце, де хтось вводить рахунки на екрані. Це фінансовий відділ компанії, що перевіряє кожен рахунок, хто його надіслав, що компанія погодилася купити і чи варто його оплачувати. Ось найпростіше визначення. Кредиторська заборгованість – це гроші, які ваша компанія винна постачальникам за товари чи послуги, які ви вже придбали. Уявіть це як розрахунковий відділ у великій будівлі. Рахунки надходять на стійку реєстрації, звіряються з документами компанії, проходять затвердження і лише тоді потрапляють до особи, яка проводить оплату.

Ми простежимо цей шлях від запису про постачальника до фінальної відмітки про оплату. У Dynamics 365 це називається розрахунком. Чому існує кредиторська заборгованість? Уявіть, що ви керуєте невеликою компанією, яка продає офісні меблі. Вам потрібні столи, перш ніж ви зможете їх продати. А ще вам потрібні пакувальні коробки, послуги прибирання, інтернет, запчастини і, можливо, служба доставки. Якби вам доводилося платити кожному постачальнику в момент замовлення, купувати щось стало б дуже складно. Більшість підприємств купують спочатку, а платять згодом на узгоджених умовах. Постачальник доставляє товар або виконує роботу, а потім надсилає рахунок фактуру. Ваша компанія тепер винна цю суму, але вона не відправляє гроші, не перевіривши попередньо всі деталі. Ця неоплачена сума відображається в бухгалтерському обліку компанії як зобов'язання. Зобов'язання може звучати як страшний фінансовий термін, але значення просте – це сума, яку компанія винна комусь іншому.

Якщо ваш бізнес отримує рахунок за офісне приладдя і ще не оплатив його, цей рахунок належить до кредиторської заборгованості, доки оплата його не закриє. Компанія все ще має готівку зараз, але в неї також є обіцянка, яку треба виконати. Це важливо, оскільки банківський рахунок бізнесу може виглядати здоровим, поки компанія накопичує купу неоплачених рахунків. Фінансовим командам потрібно бачити обидва боки. Скільки готівки лежить у банку і скільки з цієї суми незабаром доведеться витратити. До появи інтегрованих фінансових систем ця робота часто перетворювалася на паперову тяганину. Рахунок міг надійти поштою, лежати на чиємусь столі, потім подорожувати внутрішньою поштою на затвердження, тоді як інший рахунок чекав у поштовій скринці. Хтось міг вводити той самий рахунок у таблицю, тоді як інша особа вносила його в бухгалтерську систему. Це створює знайомі проблеми. Менеджер пропускає лист із запитом на погодження, рахунок оплачується із запізненням, або постачальник надсилає той самий рахунок ще раз, і ніхто не помічає, що він уже в фінансовому відділі.

Гірше того, його можуть оплатити двічі, бо паперова та електронна копії виглядають як різні рахунки. Dynamics 365 надає компанії єдине місце для відстеження цієї роботи. Система фіксує заборгованість компанії, допомагає перевіряти рахунки та забезпечує чіткий шлях від отримання рахунку до його оплати. Це не означає, що кожен рахунок проходить без участі людини. Фінансовий відділ все одно вирішує, коли щось виглядає підозріло, але система надає їм записи та правила для прийняття рішень безбіганени з паперами. Можливо, ви також чули про дебіторську заборгованість у цій же розмові. Назви звучать майже однаково, але вони стосуються протилежних процесів. Кредиторська заборгованість відстежує кошти, що виходять із компанії, бо ви винні постачальникам. Дебіторська заборгованість відстежує кошти, що надходять до компанії, бо клієнти винні вам. Якщо ваша компанія купує принтери у постачальника, цей рахунок потрапляє до кредиторської заборгованості.

Якщо ваша компанія продає столи клієнту і надсилає йому рахунок, цей рахунок потрапляє до дебіторської заборгованості. Отже, кредиторська заборгованість відстежує те, що ви повинні сплатити, а дебіторська – те, що мають сплатити вам. Мета кредиторської заборгованості – дуже практичний результат. Сплатити потрібному постачальнику потрібну суму в узгоджену дату. Сплатити занадто рано – компанія втрачає готівку раніше, ніж потрібно. Сплатити занадто пізно – постачальник може вимагати оплату або скасувати вигідні умови. Сплатити неправильну суму – і комусь доведеться виправляти помилку пізніше, часто з купою листів, кредитнот та розчарувань. Тому, перш ніж рахунок пройде через цей процес, Dynamics 365 має точно знати, хто є постачальником і які правила стосуються цих відносин. Створення бази постачальників Отже, перш ніж Dynamics 365 зможе опрацювати бодай один рахунок, вона має знати, хто його надіслав.

Ось тут і з'являється картка постачальника. Без неї система не знає, кому платити або яких правил дотримуватися. Постачальник може надавати фізичні товари, як-от папір, ноутбуки чи запчастини. Вони також можуть надавати послуги, як-от бухгалтерський облік чи підтримку програмного забезпечення. Продукт змінюється, але роль залишається незмінною. Це сторона, який ваша компанія, можливо, має заплатити. Вважайте картку постачальника його особовою справою в Dynamics 365. Вона зберігає основні дані, потрібні фінансовому відділу, а також визначає правила, що регулюють подальші дії. Ви вносите назву постачальника, адресу та контактні дані, щоб компанія точно знала, з ким має справу. Ви також можете вказати валюту, що використовується для рахунків і платежів, що дуже важливо при закупівлях у постачальників з різних країн. Тепер щодо платіжних реквізитів, запис постачальника може містити умови оплати та спосіб розрахунку.

Це можуть здатися лише маленькими полями на екрані, але вони дають відповіді на цілком практичні питання. Коли потрібно платити цьому постачальнику? І яким чином компанія має надіслати кошти? Умови оплати визначають правила щодо термінів погашення. Деякі постачальники дозволяють платити через 30 днів після дати виставлення рахунку. Інші вимагають оплату протягом 14 днів. Деякі навіть пропонують знижку за дострокову оплату. Dynamics 365 використовує введені вами умови, щоб автоматично розраховувати термін оплати кожного рахунку. Нікому не потрібно запам'ятовувати умови договору. Це забезпечує послідовність. Якщо п'ятеро різних людей обробляють рахунки одного постачальника, вони всі дотримуються однакових правил оплати. Нікому не потрібно шукати в старих електронних листах або телефонувати до відділу закупівель, щоб запитати, коли оплатити рахунок. Спосіб оплати описує, як саме кошти надходять отримувачу.

Ваша компанія може платити одному постачальнику електронним переказом, іншому – чеком. У деяких випадках бізнес також може використовувати в екселі. Dynamics 365 дозволяє визначати власні способи оплати та за потреби пов'язувати їх із системними типами. Компанії зазвичай працюють не з одним постачальником. У компанії, що розвивається, їх можуть бути десятки, сотні або навіть тисячі. Налаштування кожного з них з нуля було б марнуванням часу та джерелом помилок. Ось чому в Dynamics 365 використовуються групи постачальників. Група постачальників об'єднує тих, на кого поширюються однакові загальні фінансові правила. Наприклад, ви можете додати місцевих постачальників офісного приладдя до однієї групи, а закордонних постачальників – товарів – до іншої. Група містить спільні налаштування для відображення транзакцій, порядку проведення платежів та взаєморозрахунків, а також звітності щодо залишків за цими постачальниками.

Ви все одно зберігаєте окремий запис для кожного постачальника. Це важливо, оскільки кожен постачальник має власну назву, адресу, платіжні дані та історію. Група постачальників лише забезпечує спільну відправну точку, щоб фінансовому відділу не доводилося щоразу переналаштовувати одні і ті самі правила. За лаштунками є ще один елемент, який називається профілем обліку постачальника. Назва звучить технічно, тож давайте пояснимо її простішою мовою. Профіль обліку – це своє рідна карта, яка вказує Dynamics 365, до якого рахунку головної книги належать транзакції постачальника. Головна книга – це основний реєстр фінансових рахунків компанії. Коли рахунок проводиться в системі Dynamics 365, має зафіксувати як заборгованість компанії, так і те, до якої статті витрат це відноситься. Профіль обліку спрямовує бухгалтерське відображення операції з постачальником відповідно до правил, встановлених для постачальника або групи постачальників.

Працівникам фінансового відділу не потрібно щоразу обирати ці рахунки з пам'яті. Натомість система використовує схему, що зменшує кількість суперечливих записів і надає фінансовій команді значно чіткіше уявлення про заборгованість перед постачальниками. Компанія також готує процес оплати ще до надходження рахунків. У модулі управління готівкою та банківськими операціями ви налаштовуєте банківські рахунки, з яких здійснюватимуться виплати постачальникам. Журнали платежів надають фінансовим працівникам робочий простір для підготовки та реєстрації цих платежів за допомогою затверджених методів. Отже, підсумуємо, картка постачальника визначає, хто отримує кошти. Умови оплати визначають термін платежу, а спосіб оплати та банківський рахунок, як саме кошти, залишають компанію. З готовими правилами рахунок може надійти до фінансового відділу та почати свій шлях від отримання до затвердження. За наявності картки постачальника, Dynamics 365 тепер знає, кому платити та за якими правилами.

Отже, що відбувається, коли надходить фактичний рахунок. Іноді фінансовий працівник вводить його вручну. Це працює, коли рахунок надходить електронною поштою, на папері або через портал постачальника, і комусь потрібно ввести деталі в систему. Працівник обирає постачальника, вводить номер рахунку та дату, а потім додає рядки, суми, податки та будь-яке посилання на замовлення на закупівлю, що стосується цього рахунку. Номер рахунку заслуговує на увагу. Він надається постачальником, а не вашою компанією, і допомагає ідентифікувати конкретний рахунок. Якщо надходить рахунок на 1200 доларів відносвін до Office Supplies з номером N148, Dynamics 365 може використати цей номер разом із карткою постачальника, щоб виявити дублювання запису. Вкладення також належать до запису. Рахунок у форматі PDF, скануваний документ або супровідні папери можуть зберігатися разом із рахунком у Dynamics 365. Це означає, що особа, яка перевіряє запис, може бачити документ за цифрами, не перериваючи спільну поштову скриньку чи шафу з документами.

Для більших обсягів рахунки можуть надходити в електронному вигляді. Dynamics 365 підтримує імпорт даних рахунків за допомогою об'єктів даних. Уявіть об'єкт даних як стандартну форму, яку інша система може заповнити перед надсиленням інформації до Dynamics 365. Зовнішній сервіс для отримання рахунків, наприклад, може надіслати заголовок рахунку, рядки та вкладений документ в одному пакеті даних. Заголовок містить основні дані рахунку, постачальника, номер рахунку, дати, валюту, загальну суму та посилання на замовлення на закупівлю. Рядки пояснюють, за що з вас стягується плата. Один рядок може стосуватися паперу для принтера, інший – тонера, а ще один – доставки. Розділення цих деталей допомагає фінансовим працівникам бачити саме те, що вони затверджують. Податкова інформація також супроводжує рахунок. Dynamics 365 потребує суми податку та відповідних даних, щоб компанія правильно зареєструвала рахунок.

Кілька факторів можуть зупинити обробку рахунка до його перевірки. Відсутній постачальник, недійсна дата, повторний номер рахунка або невідповідна загальна сума. Ця пауза захищає компанію. Політика щодо рахунків постачальників перевіряє, чи відповідає рахунок правилам, встановленим вашою компанією. Перевірка на дублікати шукає знайомі рахунки, наприклад, коли такий самий постачальник і номер рахунка вже зареєстровані. Мета полягає не в тому, щоб звинуватити постачальника в помилці. Постачальники можуть надсилати рахунок повторно, бо не впевнені, чи він дійшов. Працівник може помилково ввести той самий PDF-файл двічі. У будь-якому разі подвійна оплата одного рахунка створює нікому непотрібну роботу. Як тільки Dynamics 365 приймає рахунок, виникає просте запитання. Хто має право його затвердити? Ось тут у гру вступає робочий процес Workflow. Робочий процес – це маршрут затвердження всередині системи.

Замість того, щоб надсилати PDF-файл менеджеру і сподіватися на відповідь, Dynamics 365 надсилає рахунок особі або на посаду, визначену правилами вашої компанії. Кожна організація сама визначає ці правила, виходячи з того, як мають прийматися фінансові рішення. Невеликий поточний рахунок може пройти короткий шлях. Рахунок на суму, що перевищує певну межу, може потребувати підтвердження старшого менеджера. Рахунок, пов'язаний із конкретним відділом, може потрапити до керівника цього відділу. Ви можете створити різні шляхи затвердження для різних типів постачальників, наприклад, постачальників товарів, послуг або підрядників. Маршрут слідує правилам, а не чиїсь пам'яті. Це значно полегшує відстеження затверджень. Фінансовий відділ бачить, чи рахунок чекає на перевірку, чи вже затверджений, чи потребує додаткової інформації. Особа, що затверджує рахунок, може перевірити його, визначити, чи належить він до її відділу і чи коректна вказана сума.

Деякі рахунки відповідають усім правилам і просуваються автоматично. Постачальник відомий імпортовані дані повні, а рахунок проходить перевірку політикою. Такі рахунки не потребують постійного повторення одних і тих самих базових перевірок. Інші рахунки стають винятками. Можливо, відсутній обліковий запис постачальника. Можливо, такий номер рахунка вже існує. Можливо, в імпортованому рядку є помилка. Dynamics 365 зберігає такі рахунки у списку помилок імпорту, де фінансовий персонал може побачити повідомлення про помилку та виправити проблему перед створенням рахунка до оплати. Документ залишається важливим під час перевірки. Dynamics 365 включає засіб перегляду вкладень на сторінках рахунків, тому фінансовий працівник може бачити зображення рахунка поруч із записом, який виправляє. Не потрібно перемикатися між екранами лише для того, щоб підтвердити, чи ввів постачальник 6 тисяч чи 8 тисяч в оригінальному рахунку.

Автоматизація обробляє рутинні дії. Люди вирішують питання. Затвердження підтверджує, що потрібна особа погодила рахунок до оплати, але це ще не доводить, що постачальник виставив рахунок саме за те, що було замовлено або отримано. Для цього Dynamics 365 порівнює документацію. Звірка рахунків. Перевірка того, що компанія замовила, підтверджує, що потрібна особа ознайомилася з рахунком. Але звірка відповідає на інше запитання. Чи збігається рахунок із тим, що компанія справді погодилася купити? Коли закупівля починається із замовлення на купівлю, у Dynamics 365 є запис для перевірки. Уявіть замовлення на купівлю як внутрішній документ компанії. У ньому фіксується постачальник, запитані товари, кількість, ціна та умови. Хтось із відділу закупівель створює це замовлення до надходження будь-якого рахунку. Чому це важливо? Замовлення на купівлю фіксує домовленості ще до появи рахунку. Без нього фінансист бачить лише рахунок на ім'я постачальника.

З ним він може порівняти нарахування постачальника з початковим запитом. Для фізичних товарів важливий ще один запис. Коли доставка прибуває, складська команда реєструє надходження продукції. Це доказ у Dynamics 365, що товар отримано разом із кількістю. Це не означає, що кожен товар ідеальний, але це фіксує отримане за цим замовленням. Уявіть, що компанія замовляє 10 офісних стільців. У замовленні вказано 10 стільців за узгодженою ціною, але коли прибуває вантажівка, на складі налічують лише 8, бо 2 на дозамовленні. Команда з приймання створює документ про отримання на 8 одиниць. Потім постачальник надсилає рахунок на 10 стільців, що може бути правильним з їхньої точки зору, якщо вони виставили рахунок до відправлення решти. Але тепер у вашій компанії виникла розбіжність. Замовлено 10, отримано 8, рахунок на 10. Dynamics 365 може виявити цю різницю через звірку рахунків. Двостороння звірка порівнює замовлення на купівлю з рахунком постачальника, перевіряючи, чи збігається рахунок із замовленням за ціною та кількістю.

Це підходить для закупівель, де перевірки початкового замовлення достатньо для контролю. Вона виявляє завищену ціну або більшу кількість, ніж замовлено, але не перевіряє, чи прибув товар, бо порівнює лише два записи – замовлення та рахунок. Тристороння звірка додає документ про отримання продукції. Тож тепер Dynamics 365 порівнює замовлення, акт отримання та рахунок разом. У нашому прикладі зі стільцями система бачить замовлення на 10, отримання на 8 і рахунок на 10. І ця розбіжність стає причиною зупинити рахунок замість того, щоб проводити його далі. Для компаній, що купують запаси чи обладнання, ця перевірка дає фінансистам кращий контроль, допомагаючи уникнути оплати за неотримані чи зайві товари. Відділ закупівель підтверджує домовленості. Відділ прийому підтверджує отримане, а рахунок від постачальника вимагає оплати. Ой, усі три записи мають свідчити про одне і те саме. У реальному бізнесі трапляються невеликі розбіжності.

Ціна може відрізнятися через округлення, або постачальник може внести незначно допустиму зміну в кількість. Якби кожна дрібна розбіжність зупиняла рахунок, фінансові команди витрачали б забагато часу на вирішення несуттєвих питань. Тому Dynamics 365 дозволяє компанії встановлювати політики зі ставлення та межі допустимих відхилень. Допустиме відхилення – це дозволена різниця, компанія сама вирішує, яку суму чи відсоток приймати для ціни, кількості, загального підсумку чи пов'язаних витрат. Все, що в межах цього ліміту, обробляється за правилами компанії, а все, що виходить за межі, позначається для перевірки. Компанія сама визначає ці ліміти. Бізнес може дозволити невелику різницю для дешевих офісних товарів, але встановити значно суворіші ліміти для дорогого обладнання. Система не вирішує, що є прийнятним. Фінансовий та закупівельний відділи встановлюють правила, а Dynamics 365 послідовно їх застосовує.

Це змінює те, як фінансова команда витрачає свій час. Замість перевірки кожного безпроблемного рахунку рядок за рядком, вони можуть зосередитися на винятках. О, досліджуючи рахунок, де змінилася ціна, відсутній акт прийому або не сходиться кількість. Чисті рахунки все одно дотримуються правил, але люди приділяють увагу там, де потрібне рішення. У цьому справжня цінність зіставлення. Система бере на себе рутинні перевірки, тоді як люди вирішують питання, що потребують судження. Система не замінює людське судження. Вона відокремлює рутинні перевірки від справжніх питань. Один момент може викликати плутанину. Стандартне зіставлення у Dynamics 365 підтримує двостороннє та тристороннє звіряння. Якщо компанії потрібне чотиристороннє звіряння, наприклад, із додаванням акту перевірки, це потребує додаткової роботи через налаштування або інше рішення. Отже, у зіставлення чітке завдання. АУ. Воно порівнює рахунок постачальника з власними записами закупівель та отримання товарів компанії, вказуючи на прогалини перед оплатою.

Як тільки рахунок проходить перевірку та зіставлення, він стає боргом, який компанія планує сплатити, розраховуючись із постачальниками та закриваючи звіти. Після того, як рахунок проходить необхідні компанії перевірки, Dynamics 365 може його провести. Проведення означає, що рахунок стає офіційним фінансовим записом і компанія фіксує борг перед постачальником, при цьому рахунок відображається як неоплачений до моменту виплати. Рахунок готовий, але це не означає, що гроші відразу йдуть з рахунку. Фінансові команди мають вирішити, які рахунки оплатити під час платіжного циклу. Dynamics 365 допомагає з пропозицією щодо оплати, яка переглядає рахунки до сплати та рекомендує, які з них включити у виплату згідно з правилами компанії. Пропозиція щодо оплати – це початковий список, який ще має перевірити відповідальна особа. Можливо, термін оплати рахунка від постачальника припадає на цей тиждень, тоді як інший може зачекати до кінця місяця згідно з узгодженими умовами.

Фінансовий відділ перевіряє запропоновані рахунки, за потреби додає або видаляє позиції, а потім готує платіжний журнал. Таким чином платежі групуються та контролюються, замість того, щоб здійснюватися хаотично. Вважайте платіжний журнал робочим документом компанії для здійснення виплат. У ньому перелічено платежі постачальникам, які планує здійснити компанія, суми та реквізити платежів. Фінансові фахівці використовують його для підготовки контрольованого пакету платежів, замість надсилання грошей за кожним рахунком окремо без спільного запису. Як кошти виходять з рахунку? Це залежить від способу оплати, встановленого для постачальника та компанії. Dynamics 365 дозволяє компанії створювати власні методи оплати та пов'язувати їх із типами платежів, як от чеки, електронні перекази або векселі. Чек – це знайомий інструмент. Електронний платіж надсилає кошти через банківську систему компанії.

Вексель фіксує офіційне зобов'язання щодо оплати на узгоджених умовах. Не кожен бізнес використовує всі методи, але Dynamics 365 надає компанії спосіб зафіксувати обраний маршрут платежів. Кожен метод оплати також повинен бути пов'язаний із правильним банківським рахунком компанії. Цей зв'язок важливий, оскільки бізнес може мати окремі рахунки для різних юридичних осіб, валют або цілий платежі. Коли фінансовий відділ готує платіж, системі потрібно знати, з якого банківського рахунку він здійснюється. Інакше персонал може створити правильний платіж, але списати його з неправильного рахунку. Час здійснення платежів також потребує уваги. Оплата після настання терміну може призвести до нагадувань, суперечок або пошкодження стосунків із постачальником. Занадто рання оплата виводить готівку з обороту тоді, коли в цьому ще немає потреби. Dynamics 365 відображає термін оплати рахунків, щоб фінансовий відділ міг планувати платежі відповідно до умов, узгоджених із кожним постачальником, надаючи компанії кращий контроль над відтоком коштів.

Dynamics 365 має дати відповідь на просте запитання. Який саме рахунок покриває цей платіж? Відповідь – взаємозалік. Взаємозалік пов'язує платіж із конкретним рахунком або рахунками постачальника, які він оплачує. Уявіть це як відповідність чека рахунку, який він закриває. Без взаємозаліку компанія може бачити рахунок і платіж на одному рахунку постачальника, але не мати чіткого запису про те, що вони пов'язані. Повна оплата закриває рахунок повністю, але в бізнесі не завжди все так просто. Компанія може оплатити лише частину рахунка зараз, а решту – пізніше. Взаємозалік фіксує часткову оплату та залишає решту суми відкритою, щоб фінансовий відділ бачив, скільки компанія ще винна постачальнику. Ця прозорість є критично важливою для точного відображення заборгованості перед постачальниками. Один платіж також може покривати кілька рахунків. Можливо, компанія сплачує п'ять рахунків від одного постачальника одним електронним платежем.

Взаємозалік пов'язує цю єдину суму виплати з кожним рахунком, який вона закриває. Якщо платіж не покриває кожен рахунок повністю, відкритий залишок залишається чітким, а не зникає у загальній заплутаній сумі. Це створює простежуваний запис, і ви можете простежити рахунок від його затвердження до результату зіставлення. Перегляньте платіж, підготовлений у журналі, і побачите, як саме цей платіж погасив заборгованість постачальника. Коли хтось запитує, чому кошти залишили компанію, Фінансовому відділу не потрібно відновлювати історію за електронними листами та банківськими виписками. Процес може відображатися на окремих сторінках у Dynamics 365, але кожен запис з'єднується з наступним як один контрольований потік – повна картина кредиторської заборгованості. Уявіть, що ви отримали один рахунок за канцелярські товари. Запис постачальника містить правила оплати, а імпортований рахунок додає деталі оплати та сам документ.

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