У призначенні китайського supplier payment збережіть щонайменше contract number і date, invoice number та короткий опис товару або послуги. Якщо банк дає окремі structured fields, не дублюйте все у free text: legal names мають бути в party data, сума й валюта — в amount fields, а remittance reference повинен однозначно вести до комерційних документів.
Проблема виникає під час переходу з ERP до bank portal: довгий опис обрізається, slash або non-Latin characters відхиляються, а співробітник скорочує саме invoice number. У результаті китайський supplier бачить гроші, але не може автоматично закрити receivable або пов’язати суму з конкретною партією.
Інформацію та офіційні джерела перевірено 2026-08-02. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | компанія, що подає supplier payment через банк або treasury platform |
| Кому | китайський продавець товару чи виконавець послуги |
| Мета | передати достатні commercial references для compliance і reconciliation |
| Валюта / інструмент | ISO 20022 instruction або банківська форма з structured та free-text fields |
| Що змінює висновок | character limit, allowed symbols, contract and invoice identifiers, remittance structure, address format і bank-specific purpose codes |
Що потрібно знати до платежу
ISO 20022 став основою CBPR+ instructions
Swift підтверджує, що coexistence period для cross-border payment instructions завершився 22 листопада 2025 року. Це підвищує значення структурованих полів, але клієнт усе одно має перевірити, які саме дані його банк приймає та передає далі. (Swift, ISO 20022 implementation)
Unstructured address виводиться з CBPR+
Roadmap Swift передбачає, що після Standards Release 2026 usage guidelines дозволятимуть fully structured або hybrid postal address, а unstructured option буде видалена. Змішувати адресу beneficiary з payment purpose стає ще менш виправдано. (Swift, roadmap beyond Nov 2025)
Commercial reference повинен вести до shipment data
Поля китайської митної декларації описують учасників, товар, кількість і вартість. Номер контракту та invoice у remittance information створюють зв’язок між банківським записом і цим зовнішньоторговельним набором. (GACC, стандарти декларації)
Універсального purpose code для всіх банків немає
SAFE публікує окремі current-account questions для різних типів торгівлі, а конкретна банківська форма може мати власний довідник. Код із чужої інструкції не слід переносити без звірки economic purpose. (SAFE, FAQ за поточними операціями)
Покрокова підготовка
- Створіть canonical reference. У внутрішньому payment request запишіть незмінний рядок із contract number/date, invoice number та order або shipment ID; власником шаблону призначте treasury.
- Розкладіть дані по полях. Beneficiary name, address, amount, currency і account identifiers внесіть у відповідні structured elements, залишивши remittance text для комерційного зв’язку.
- Перевірте технічні обмеження. До submission з’ясуйте maximum length, дозволені символи, правила transliteration і порядок обрізання; зробіть preview саме того повідомлення, яке піде з банку.
- Погодьте reference з постачальником. Надішліть finance contact короткий зразок і переконайтеся, що за invoice number та order ID він знайде receivable без додаткового листування.
- Збережіть фінальну версію повідомлення. Архівуйте bank confirmation із фактично переданим remittance information, а не лише чернетку з ERP; під час reconciliation порівняйте обидва рядки.
Які дані та документи зібрати
- контракт із номером і датою, що використовуються без альтернативних скорочень
- invoice з унікальним identifier та зрозумілим описом предмета
- field map банківського порталу з length і character restrictions
- payment confirmation, де видно remittance reference після відправлення
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Treasury підготувала оплату трьох інвойсів одного постачальника. ERP сформувала довгий текст, але bank portal залишав лише 70 символів, через що всі рядки закінчувалися до invoice number. Команда перенесла party data у structured fields, поставила contract identifier першим, а потім три invoice numbers у погодженому форматі. Supplier finance team закрила кожний receivable без ручного пошуку за сумою.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- писати лише «payment for goods» без contract та invoice identifiers
- вставляти адресу й legal name у поле, призначене для commercial reference
- скорочувати різні invoices до однакового набору перших символів
- копіювати purpose code з форуму, не звіривши його з банком і видом операції
Де проходить межа поради
Остаточні вимоги залежать від юрисдикції, банку, платіжного провайдера, статусу сторін і призначення операції.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay приймає таку заявку на індивідуальну перевірку; менеджер підтвердить доступність, курс, підсумкову суму, реквізити та орієнтовний строк до оплати. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
- SAFE, FAQ за поточними операціями
- GACC, стандарти декларації
- Swift, ISO 20022 implementation
- Swift, roadmap beyond Nov 2025
Дата редакційної перевірки: 2026-08-02.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.