बैंक और भुगतान इम्पोर्ट (Bank & payment imports)

camt.053 विवरण (statements), Stripe CSV, PSP निपटान मिलान (settlement reconciliation) और कस्टम JSON फ़ीड्स।

सभी इम्पोर्ट बैंक खाते (bank/accounts/create) पर बैंक लेन-देन (bank transactions) के रूप में आते हैं। लेन-देन में एक externalId होती है; एक ही फ़ाइल को दोबारा इम्पोर्ट करना सुरक्षित है - जिन पंक्तियों (rows) की (bankAccountId, externalId) पहले से मौजूद होती हैं, उन्हें छोड़ दिया जाता है और skipped काउंटर में उनकी रिपोर्ट दी जाती है। इम्पोर्ट किए गए लेन-देन new स्थिति में शुरू होते हैं और केवल मिलान होने पर ही लेज़र में पोस्ट किए जाते हैं (bank/transactions/match, उम्मीदवारों के लिए bank/transactions/suggest-matches के साथ)।

वेब ऐप बैंक → फ़ाइल इम्पोर्ट करें (Bank → Import file) के तहत समान इम्पोर्ट दिखाता है (फ़ाइल अपलोड, टेम्प्लेट चयनकर्ता)।

गलत मिलान को bank/transactions/unmatch (बैंक → लेन-देन (Bank → Transactions) में अनमैच (Unmatch)) के साथ पूर्ववत (undo) किया जाता है। पोस्ट की गई प्रविष्टियों को कभी भी संपादित या हटाया नहीं जाता है: किसी चालान (invoice) से मिलाया गया भुगतान, या इम्पोर्ट टेम्प्लेट द्वारा किसी खाते में पोस्ट की गई पंक्ति को विपरीत पक्ष में प्रत्येक प्रविष्टि के साथ एक रिवर्सिंग जर्नल लेन-देन मिलता है, जिसकी तिथि date होती है (डिफ़ॉल्ट: आज, और मूल पोस्टिंग से पहले कभी नहीं)। चालान की भुगतान की गई राशि और भुगतान स्थिति उस बैंक पंक्ति की राशि से वापस चली जाती है। भुगतान-प्रदाता (payment-provider) निपटान से जुड़ी एक पंक्ति को केवल अनलिक किया जाता है, क्योंकि निपटान पोस्टिंग बैच से संबंधित होती है। पंक्ति वापस new स्थिति में आ जाती है और उसे फिर से मिलाया जा सकता है। रिवर्सल की तिथि एक खुली लेखांकन अवधि (accounting period) के भीतर आनी चाहिए।

इम्पोर्ट टेम्प्लेट (Import templates)

एक इम्पोर्ट टेम्प्लेट डेटा स्रोत (data source) का नाम देता है, स्रोत द्वारा प्रदान किए जाने वाले फ़ील्ड की सूची बनाता है, और लेज़र खातों में धन ले जाने वाले फ़ील्ड को मैप करता है। टेम्प्लेट बैंक → इम्पोर्ट टेम्प्लेट (Bank → Import templates) के तहत और bank/import-templates/create|update|delete|get|list के माध्यम से प्रबंधित किए जाते हैं।

POST /v1/bank/import-templates/create
{
  "name": "Stripe payments export",
  "type": "stripe",
  "fields": [
    { "name": "id" },
    { "name": "Created date (UTC)" },
    { "name": "Amount" },
    { "name": "Fee", "accountCode": "6800" },
    { "name": "Amount Refunded" }
  ],
  "metaFields": ["order_id"]
}

type में stripe, iso20022, bank_connection या revolut में से कोई एक होना चाहिए।
प्रत्येक फ़ील्ड में एक name और एक वैकल्पिक accountCode होता है। केवल धन ले जाने वाले फ़ील्ड ही खाता स्वीकार करते हैं: Stripe Amount, Fee और Amount Refunded; camt.053 Ntry/Amt; बैंक फ़ीड transaction_amount.amount। खाता चार्ट ऑफ़ अकाउंट्स (chart of accounts) में मौजूद होना चाहिए (ledger/accounts/create के साथ इसे बनाएं)।
fields को छोड़ा जा सकता है; इसके बाद यह डिफ़ॉल्ट रूप से उस प्रकार की मानक फ़ील्ड सूची पर सेट हो जाता है: Stripe भुगतान → निर्यात (Payments → Export) फ़ाइल के कॉलम नाम (19 Card … कॉलम को छोड़कर, जिन्हें फ़ॉर्म डिफ़ॉल्ट रूप से अनचेक भी छोड़ देता है), camt.053 तत्व जो प्रत्येक विवरण में होते हैं (Stmt/Id, Stmt/Acct/Id/IBAN, Stmt/Bal/…, Ntry/Amt, Ntry/CdtDbtInd, Ntry/Sts, Ntry/BookgDt), या वे विशेषताएँ (attributes) जिन्हें PSD2 बैंक फ़ीड प्रति लेन-देन लौटाता है। अपनी फ़ाइल से मिलाने के लिए प्रविष्टियाँ जोड़ें या हटाएँ: इम्पोर्टर वैकल्पिक camt.053 तत्वों Ntry/ValDt, Ntry/NtryRef, Ntry/AcctSvcrRef, Ntry/AddtlNtryInf, TxDtls/Refs/EndToEndId, TxDtls/Refs/TxId, TxDtls/RltdPties/Dbtr/Nm, TxDtls/RltdPties/DbtrAcct/Id/IBAN, TxDtls/RltdPties/Cdtr/Nm, TxDtls/RltdPties/CdtrAcct/Id/IBAN, TxDtls/RmtInf/Ustrd और TxDtls/AddtlTxInf को भी पढ़ता है।
Stripe का Customer Email फ़ील्ड "createPartner": true ले जा सकता है। इसके बाद इम्पोर्ट फ़ाइल में मौजूद प्रत्येक उस ईमेल के लिए एक ग्राहक (व्यक्ति प्रकार का पार्टनर, जिसे ग्राहक के रूप में चिह्नित किया गया है) बनाता है जो किसी मौजूदा पार्टनर के पास नहीं है, जिसमें नाम के रूप में Customer Description का उपयोग किया जाता है (खाली होने पर ईमेल) और जब फ़ाइल में Card Address … कॉलम होते हैं, तो उन्हें पते के रूप में उपयोग किया जाता है। मौजूदा पार्टनर ईमेल द्वारा, केस-असंवेदनशील (case-insensitively) तरीके से मिलाए जाते हैं। प्रतिक्रिया customersCreated में गिनती की रिपोर्ट करती है।
metaFields (केवल Stripe) आपके शुल्कों द्वारा ले जाने वाली मेटाडेटा कुंजियों की सूची बनाता है। Stripe प्रत्येक कुंजी को <key> (metadata) कॉलम के रूप में निर्यात करता है; सूची फ्री-फॉर्म (free-form) है और लंबी हो सकती है।
invoiceItemId (केवल Stripe, वैकल्पिक) एक कैटलॉग आइटम है। सेट होने पर, इम्पोर्ट द्वारा बनाई जाने वाली प्रत्येक चालान और क्रेडिट नोट पंक्ति उस आइटम को संदर्भित करती है (इसकी पोस्टिंग और, जब invoiceVatRatePercent खाली हो, तो इसका वैट दर); पंक्ति का पाठ अभी भी शुल्क से आता है।
companyMetaField (केवल Stripe) उनमें से किसी एक कुंजी को कंपनी ध्वज (flag) के रूप रूप में नाम देता है। जब कोई शुल्क उस कॉलम में true, 1, yes, company, business या b2b ले जाता है, तो इसके लिए बनाया गया ग्राहक व्यक्ति के बजाय कंपनी प्रकार का पार्टनर होता है।
invoiceMetaField (केवल Stripe) इनमें से किसी एक कुंजी का नाम देता है, उदाहरण के लिए ऑर्डर नंबर, और invoiceVatRatePercent इससे बनाए गए चालानों के लिए वैट दर का नाम देता है। इम्पोर्ट करने पर प्रत्येक शुल्क और रिफंड पंक्ति को उस कुंजी के मान द्वारा समूहीकृत किया जाता है:
- एक ऐसा मान जो किसी मौजूदा बिक्री चालान से मेल खाता हो - एक बिक्री ऑर्डर जिसका externalRef वह मान है (ecommerce/orders/create, कोई भी चैनल) या एक चालान जिसका fullNumber वह मान है - समूह को उस चालान से जोड़ता है;
- बिना चालान वाला मान एक चालान बनाता है: Customer Email से पार्टनर (गायब होने पर बनाया जाता है, जैसा कि createPartner के लिए होता है), प्रति शुल्क एक पंक्ति (Checkout Line Item Summary या Description पाठ के रूप में, invoiceVatRatePercent पर वैट-सहित मूल्य के रूप में शुल्क राशि), जारी करने की तिथि = पहला शुल्क तिथि, कंपनी और कार्ड देश से वैट उपचार। चालान को एक साथ जारी और पोस्ट किया जाता है, और stripe चैनल और उस मान को externalRef के रूप में रखने वाला एक बिक्री ऑर्डर दर्ज किया जाता है ताकि बाद के इम्पोर्ट निर्माण के बजाय लिंक करें;
- समूह में प्रत्येक शुल्क को तब भुगतान के रूप में चालान से मिलाया जाता है (रसीद पोस्ट करना); प्रत्येक रिफंड रिफंड की गई राशि के लिए चालान के विरुद्ध एक जारी किया गया क्रेडिट नोट बनाता है और रिफंड को उससे मिलाता है। गिनती invoicesCreated, invoicesLinked, creditNotesCreated और paymentsMatched के रूप में वापस आती है; जिन समूहों को संसाधित नहीं किया जा सका (कोई ग्राहक ईमेल नहीं, मिश्रित मुद्राएँ, एक जुड़ा हुआ चालान जो अभी भी एक ड्राफ्ट है या पहले से ही पूरी तरह से भुगतान किया गया है) उन्हें warnings में सूचीबद्ध किया जाता है और new बैंक लेन-देन के रूप में छोड़ दिया जाता है। उसी टेम्प्लेट में Amount को लेज़र खाते में भी मैप न करें: किसी चालान से मिलाए गए शुल्क को दूसरी बार पोस्ट नहीं किया जाता है, लेकिन एक बेजोड़ शुल्क को पोस्ट किया जाएगा।
टेम्प्लेट नाम प्रति कंपनी अद्वितीय (unique) होते हैं।
camt.053 और बैंक-कनेक्शन टेम्प्लेट में समान विकल्प होते हैं, जिन्हें Stripe कॉलम के बजाय विवरण से पढ़ा जाता है:
- लापता पार्टनर बनाएं (Create missing partners): आने वाले धन के प्रत्येक अज्ञात भुगतानकर्ता (payer) के लिए debtor नाम पंक्ति (TxDtls/RltdPties/Dbtr/Nm, फ़ीड debtor.name) पर createPartner एक ग्राहक बनाता है; जाने वाले धन के प्रत्येक अज्ञात प्राप्तकर्ता (payee) के लिए creditor नाम पंक्ति (TxDtls/RltdPties/Cdtr/Nm, फ़ीड creditor.name) पर एक आपूर्तिकर्ता (supplier) बनाता है। पार्टनर को IBAN (partner_bank_accounts में संग्रहीत) द्वारा पहचाना जाता है, फिर सटीक नाम द्वारा; जब नाम में कानूनी रूप (UAB, MB, SIA, GmbH, Ltd, …) होता है, तो एक नया पार्टनर कंपनी होता है, अन्यथा एक व्यक्ति। गिनती customersCreated (फ़ाइल इम्पोर्ट) या partnersCreated (फ़ीड सिंक) के रूप में वापस आती है।
- संदर्भ द्वारा चालान लिंक करें (Link invoices by reference): प्रेषण या संदर्भ पंक्ति (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId; फ़ीड remittance_information, reference_number) पर सेट invoiceMetaField प्रत्येक नई बैंक पंक्ति का मिलान करता है जिसका संदर्भ, प्रेषण या विवरण खुले जारी किए गए बिक्री चालान (आने वाला धन) या पंजीकृत खरीद चालान (जाने वाला धन) की संख्या contiene है, और भुगतान पोस्ट करता है। जब भुगतानकर्ता का IBAN किसी पार्टनर पर सहेजा जाता है, या भुगतानकर्ता का नाम किसी पार्टनर के नाम या कोड के बराबर होता है, तो चालान उस पार्टनर का होना चाहिए। किसी अज्ञात भुगतानकर्ता से भुगतान तभी जोड़ा जाता है जब वह चालान की शेष शेष राशि के बराबर हो और चालान संख्या में इसका श्रृंखला उपसर्ग (series prefix) हो, ताकि राशि जैसी नग्न संख्या को कभी भी संदर्भ के रूप में न लिया जाए। शेष शेष राशि से बड़ा भुगतान कभी नहीं जोड़ा जाता है। जो पंक्तियाँ इन जाँचों में विफल होती हैं वे मैन्युअल मिलान के लिए नई रहती हैं और चेतावनियों में सूचीबद्ध होती हैं। advanceInvoices: true के साथ किसी ज्ञात पार्टनर से एक बेजोड़ आने वाला भुगतान invoiceVatRatePercent या invoiceItemId दर पर राशि के लिए एक जारी अग्रिम चालान (प्रकार advance) बनाता है और भुगतान को उससे मिलाता है; पार्टनर ज्ञात होना चाहिए, इसलिए debtor पंक्ति को भी टिक करें।
- लेन-देन कोड द्वारा पोस्टिंग नियम (Posting rules by transaction code): Ntry/Amt / transaction_amount.amount के अलावा, फ़ील्ड सूची में नियम पंक्तियाँ होती हैं Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (फ़ीड: bank_transaction_code=…, credit_debit_indicator=…)। एक पंक्ति को उसके द्वारा मिलान किए जाने वाले पहले नियम के खाते में पोस्ट किया जाता है: उसका बैंक लेन-देन कोड परिवार, फिर उसकी दिशा, फिर सादा राशि पंक्ति। नियम पंक्तियों की फ़ाइल के विरुद्ध जाँच नहीं की जाती है।
- बैंक शुल्क पार्टनर (Bank charges partner): …=CHRG नियम पंक्ति पर createPartner बैंक के नाम पर एक आपूर्तिकर्ता बनाता है (विवरण Stmt/Acct/Svcr/FinInstnId/Nm, या कनेक्शन का बैंक, या लेज़र बैंक खाता नाम) और उस पार्टनर के साथ प्रत्येक शुल्क को बुक करता है।
- बैंक-कनेक्शन टेम्प्लेट को bank/feeds/accounts/configure (ऐप में बैंक → कनेक्शन) के साथ प्रति फ़ीड खाता चुना जाता है, जो syncSchedule (manual, daily, weekly, monthly) भी सेट करता है: एक बार उनकी अवधि बीत जाने के बाद API अपने आप शेड्यूल वाले खातों को सिंक कर लेता है। टेम्प्लेट प्रत्येक bank/feeds/sync पर लागू होते हैं; सिंक प्रतिक्रिया तब posted, partnersCreated, invoicesLinked, invoicesCreated, paymentsMatched और warnings की रिपोर्ट भी करती है।

format के बजाय bank/statements/import में templateId पास करें: टेम्प्लेट का प्रकार पार्सर का चयन करता है, और फ़ाइल में टेम्प्लेट में सूचीबद्ध प्रत्येक फ़ील्ड होना चाहिए - इनमें से किसी भी फ़ील्ड से चूकने वाली फ़ाइल को HTTP 422 और लापता कॉलम या तत्व नामों के साथ अस्वीकार कर दिया जाता है। मेटाडेटा फ़ील्ड का मौजूद होना आवश्यक नहीं है। बैंक-कनेक्शन टेम्प्लेट लाइव PSD2 फ़ीड का वर्णन करते हैं और फ़ाइल इम्पोर्ट के लिए उपयोग नहीं किए जा सकते हैं।

एक ISO 20022 टेम्प्लेट MT940 फ़ाइलों को भी पढ़ता है: एक फ़ाइल जो {1: या :20: से शुरू होती है (या "format": "mt940" के साथ भेजी जाती है) को MT940 के रूप में पार्स किया जाता है और टेम्प्लेट के संदर्भ मिलान और पोस्टिंग नियमों को इसकी पंक्तियों पर लागू किया जाता है। MT940 के लिए तत्व जाँच को छोड़ दिया जाता है, और Ntry/BkTxCd=… नियम कभी भी MT940 पंक्तियों पर लागू नहीं होते हैं क्योंकि MT940 कोई ISO 20022 बैंक लेन-देन कोड नहीं ले जाता है; इसके बजाय Ntry/CdtDbtInd=… नियमों का उपयोग करें।

एक बैंक खाते में एक मुद्रा होती है। किसी अन्य मुद्रा में एक विवरण को HTTP 422 के साथ अस्वीकार कर दिया जाता है (एक ही IBAN के लिए कई मुद्राओं में विवरण वाली camt.053 फ़ाइल में, केवल खाते की मुद्रा में विवरण इम्पोर्ट किया जाता है), और खाते की मुद्रा के अलावा किसी अन्य currency के साथ bank/transactions/import पर भेजी गई पंक्ति को भी अस्वीकार कर दिया जाता है।

एक ऐसे फ़ील्ड से उत्पन्न होने वाली प्रत्येक गतिविधि जिसमें accountCode है, को इम्पोर्ट के समय एक जर्नल लेन-देन के रूप में पोस्ट किया जाता है: आने वाला धन बैंक खाते के लेज़र खाते को डेबिट करता है और मैप किए गए खाते को क्रेडिट करता है; जाने वाला धन मैप किए गए खाते को डेबिट करता है और बैंक खाते के लेज़र खाते को क्रेडिट करता है। गतिविधि तिथि पर राशियों को आधार मुद्रा में परिवर्तित किया जाता है। इसके बाद बैंक लेन-देन को उस जर्नल लेन-देन से matched किया जाता है (matchedDocumentType = journal_transaction) और चालान मिलान के लिए अब पेश नहीं किया जाता है। प्रतिक्रिया posted में गिनती की रिपोर्ट करती है। अनमैप किए गए फ़ील्ड से गतिविधियाँ new रहती हैं और पहले की तरह चालान से मिलाई जाती हैं - उदाहरण के लिए Fee को PSP शुल्क व्यय खाते में मैप करें और Amount को अनमैप छोड़ दें ताकि शुल्क अभी भी बिक्री चालानों से मिलान किए जा सकें।

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "…",
  "content": "id,Created date (UTC),Amount,…"
}

ISO 20022 camt.053 (ओपन बैंकिंग XML)

लिथुआनियाई बैंक (Swedbank, SEB, Luminor, Šiaulių bankas, …) आपको अपने इंटरनेट बैंकिंग से ISO 20022 camt.053 XML के रूप में खाता विवरण डाउनलोड करने देते हैं - आमतौर पर विवरण निर्यात/डाउनलोड, प्रारूप "ISO XML" या "camt.053" के तहत। समान प्रारूप PSD2 खाता-जानकारी API द्वारा लौटाया जाता है।

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"…>…"
}

एक फ़ाइल में कई विवरण हो सकते हैं; प्रत्येक विवरण का IBAN बैंक खाते के IBAN से मेल खाना चाहिए (IBAN के बिना विवरण, या बिना किसी विवरण के खाते, वैसे ही स्वीकार किए जाते हैं)।
प्रविष्टि संदर्भ (AcctSvcrRef/NtryRef, सामग्री हैश पर वापस गिरते हुए) externalId बन जाते हैं।
प्रतिक्रिया प्रति-विवरण मेटाडेटा को गूँजती है: विवरण आईडी, अवधि, शुरुआती/अंतिम शेष (opening/closing balances), लेन-देन संख्या।
मिलान के लिए प्रति प्रविष्टि प्रतिपक्ष (counterparty) का नाम, IBAN और भुगतान उद्देश्य निकाला जाता है।

दूसरी दिशा में भुगतान bank/payments/export के माध्यम से pain.001 के रूप में निर्यात किए जाते हैं।

Revolut Business CSV

Revolut Business खाते के लेन-देन विवरण को CSV के रूप में डाउनलोड करें और इसे अंतर्निहित टेम्प्लेट Revolut Business (templateId: "builtin-revolut") के साथ इम्पोर्ट करें। प्रत्येक कंपनी के पास इसे बनाए बिना यह टेम्प्लेट होता है: bank/import-templates/list-builtin इसे सूचीबद्ध करता है, bank/import-templates/get इसे लौटाता है, और bank/import-templates/update और bank/import-templates/delete इसे HTTP 400 के साथ अस्वीकार करते हैं। ऐप में यह बैंक → इम्पोर्ट टेम्प्लेट (Bank → Import templates) के तहत पहले सूचीबद्ध होता है; इसे खोलने पर इसकी सेटिंग दिखाई देती है, और सहेजने पर आपकी खुद की एक कंपनी टेम्प्लेट बनती है जिसे आप बदल सकते हैं।

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "builtin-revolut",
  "content": "Date started (UTC),Date completed (UTC),ID,Type,State,…"
}

केवल State = COMPLETED वाली पंक्तियाँ इम्पोर्ट की जाती हैं। अन्य पंक्तियों (उदाहरण के लिए PENDING) को छोड़ दिया जाता है और warnings में गिना जाता है; उन्हें एक फ़ाइल के बाद के इम्पोर्ट द्वारा इम्पोर्ट किया जाता है जिसमें वे पूर्ण हो जाती हैं।
प्रत्येक पंक्ति Date completed (UTC) की तिथि, Total amount की राशि, Payment currency की मुद्रा, externalId के रूप में ID और विवरण के रूप में Description के साथ एक बैंक लेन-देन बन जाती है।
जाने वाले धन का प्रतिपक्ष Beneficiary name और Beneficiary IBAN होता है; लाभार्थी के बिना कार्ड भुगतान के लिए, Description में व्यापारी (merchant) होता है। आने वाले धन का प्रतिपक्ष Sender name और Sender account होता है।
पंक्तियों को खाते और मुद्रा द्वारा समूहीकृत किया जाता है। International account number बैंक खाते के IBAN से मेल खाना चाहिए, और केवल बैंक खाते की मुद्रा में पंक्तियाँ इम्पोर्ट की जाती हैं।
प्रत्येक पंक्ति के लिए इम्पोर्टर यह जाँचता है कि पिछली पंक्ति का शेष प्लस Total amount, Balance के बराबर है या नहीं, और warnings में उन सभी पंक्तियों को सूचीबद्ध करता है जहाँ यह नहीं है।
फ़ाइल में कॉलम Date completed (UTC), ID, Type, State, Description, Payment currency, Total amount, Reference, Sender name और Beneficiary name होने चाहिए।

प्रत्येक इम्पोर्ट पर अंतर्निहित टेम्प्लेट:

आने वाले धन के प्रत्येक अज्ञात प्रेषक के लिए एक ग्राहक बनाता है, और जाने वाले धन के प्रत्येक अज्ञात लाभार्थी या कार्ड व्यापारी के लिए एक आपूर्तिकर्ता बनाता है, जैसा कि ऊपर लापता पार्टनर बनाएं में वर्णित है;
प्रत्येक उस पंक्ति का मिलान करता है जिसका Reference या Description किसी खुले बिक्री या खरीद चालान की संख्या शामिल करता है, और भुगतान पोस्ट करता है, ऊपर संदर्भ द्वारा चालान लिंक करें की जाँच के साथ;
उन पंक्तियों को पोस्ट करता है जिन्हें किसी भी चालान ने उनके Type द्वारा नहीं मिलाया, पोस्टिंग नियम के खाते में:

`Type`	पोस्टिंग नियम (Posting rule)	डिफ़ॉल्ट खाता	रोमानियाई चार्ट	पोस्टिंग
`FEE`	`bank.fees`	6800	627	नियम के खाते को डेबिट करें, बैंक खाते के लेज़र खाते को क्रेडिट करें; पार्टनर: बैंक खाते के नाम पर एक आपूर्तिकर्ता
`CARD_PAYMENT`	`bank.cardPayments`	6209	628	नियम के खाते को डेबिट करें, बैंक खाते के लेज़र खाते को क्रेडिट करें, बिना वैट के
`TOPUP`	`bank.topUps`	3010	1012	बैंक खाते के लेज़र खाते को डेबिट करें, नियम के खाते को क्रेडिट करें

अन्य प्रकार की पंक्तियाँ, जैसे TRANSFER, मिलान के लिए new रहती हैं।

ledger/posting-rules/update के साथ खातों को बदलें; अंतर्निहित टेम्प्लेट अगले इम्पोर्ट से नए खातों का उपयोग करता है। किसी पोस्टिंग नियम को बंद नहीं किया जा सकता है: बिना पोस्ट किए कार्ड भुगतान या टॉप-अप इम्पोर्ट करने के लिए, Type=CARD_PAYMENT या Type=TOPUP पंक्ति के बिना revolut प्रकार का एक कंपनी टेम्प्लेट बनाएं और उसके साथ इम्पोर्ट करें। इस तरह से पोस्ट किए गए कार्ड भुगतान का मिलान आपूर्तिकर्ता के चालान से तब नहीं किया जाता है जब वह चालान बाद में पंजीकृत किया जाता है; दोनों में से किसी एक को पोस्ट करें, दोनों को नहीं।

revolut प्रकार का कंपनी टेम्प्लेट समान कॉलम का उपयोग करता है और नियम पंक्तियों Type=FEE, Type=CARD_PAYMENT, Type=TRANSFER और Type=TOPUP के साथ प्रकार के अनुसार पंक्तियों को पोस्ट कर सकता है। "format": "revolut-csv" और किसी भी टेम्प्लेट के बिना इम्पोर्ट करने से इनमें से किसी भी चरण के बिना पंक्तियाँ इम्पोर्ट हो जाती हैं।

Stripe CSV

Stripe डैशबोर्ड से निर्यात करें - कोई भी रिपोर्ट काम करती है:

Reports → Balance → Itemized balance change from activity (अनुशंसित): कॉलम balance_transaction_id, created_utc, currency, gross, fee, net, reporting_category, description।
Payments → Export: कॉलम id, Created (UTC), Amount, Fee, Currency, Description, Customer Description।

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "stripe-csv",
  "content": "balance_transaction_id,created_utc,currency,gross,fee,net,…"
}

Stripe के लिए एक समर्पित बैंक खाता बनाएं (उदा. नाम "Stripe", GL खाता 2710 या इसका अपना उपखाता) - Stripe का शेष बैंक खाते की तरह व्यवहार करता है: शुल्क आते हैं, शुल्क काटे जाते हैं, भुगतान आपके वास्तविक बैंक में शेष राशि स्थानांतरित करते हैं।

इम्पोर्ट व्यवहार:

प्रत्येक शेष राशि का लेन-देन सकल (gross) राशि के लिए एक बैंक लेन-देन बन जाता है (externalId = balance transaction id)।
एक गैर-शून्य शुल्क (fee) विपरीत चिह्न के साथ एक दूसरा लेन-देन बन जाता है (externalId = <id>:fee, प्रतिपक्ष "Stripe") - ताकि शुल्क को राजस्व से अलग से व्यय के रूप में मिलाया/पोस्ट किया जा सके। रिफंड पर लौटाए गए शुल्क सकारात्मक राशियों के रूप में आते हैं।
भुगतान (Payout) पंक्तियाँ एकल नकारात्मक लेन-देन के रूप में इम्पोर्ट होती हैं; उन्हें अपने वास्तविक बैंक खाता विवरण पर संबंधित आने वाले लेन-देन के विरुद्ध मिलाएँ।
शून्य-राशि की पंक्तियों को छोड़ दिया जाता है; तिथि created_utc (UTC) से ली जाती है।
जिन भुगतान-निर्यात पंक्तियों ने कोई धन नहीं स्थानांतरित किया उन्हें छोड़ दिया जाता है: Captured = false (प्राधिकरण/देरी से कैप्चर) और Status Failed/Canceled।
एक गैर-शून्य Amount Refunded तिथि Refunded date (UTC) के साथ तीसरा, नकारात्मक लेन-देन (externalId = <id>:refund) बन जाता है - ताकि भुगतान पंक्तियों में एम्बेडेड आंशिक और पूर्ण रिफंड गायब न हों।

PSP निपटान मिलान (Stripe भुगतान रिपोर्ट)

एकमुश्त भुगतान (lump-sum payout) को उसके अंतर्निहित आदेशों, रिफंड, शुल्क और चार्जबैक में विभाजित करने के लिए, सादे विवरण इम्पोर्ट के बजाय निपटान (settlement) एंडपॉइंट का उपयोग करें। दो Stripe निर्यात स्वीकार किए जाते हैं (स्वचालित रूप से पहचाने जाते हैं):

Reports → Payouts → Payout reconciliation, itemized (रिपोर्ट प्रकार payout_reconciliation.itemized.* या payout_reconciliation.by_id.itemized.*) - सटीक, प्रति शेष राशि लेन-देन एक पंक्ति; लाइव खातों पर पसंदीदा।
Payments → Export (unified payments) - चार्ज-स्तरीय निर्यात; परीक्षण/सैंडबॉक्स मोड में काम करता है जहाँ भुगतान मिलान अनुपलब्ध है। कैप्चर किए गए शुल्कों को Transfer कॉलम में भुगतान आईडी द्वारा समूहीकृत किया जाता है; बिना कैप्चर किए गए/विफल पंक्तियों को छोड़ दिया जाता है (skippedNotSettled); एक गैर-शून्य Amount Refunded चार्ज के भुगतान बैच में एक सिंथेटिक रिफंड लाइन बन जाता है - एक अनुमान, क्योंकि रिफंड वास्तव में बाद के भुगतान मेंsettle हो सकता है। मिलान संदर्भ चार्ज आईडी, PaymentIntent ID, Invoice Number, Client Reference ID और प्रत्येक … (metadata) कॉलम (उदा. मेटाडेटा में एक ऑर्डर नंबर) से आते हैं।

एक CSV कई भुगतानों में फैला हो सकता है। Stripe आइटमयुक्त रिपोर्ट प्रति अनुभाग एक फ़ाइल (…_charge_…, …_refund_…, …_fee_…) डाउनलोड करता है; उन सभी को इम्पोर्ट करें - पहले से इम्पोर्ट किए गए भुगतान के लिए पंक्तियाँ मौजूदा बैच में विलीन हो जाती हैं (updated काउंटर में रिपोर्ट की जाती हैं) जब तक कि इसे अभी तक पोस्ट नहीं किया गया है, और बैच कुल की पुनर्गणना की जाती है।

POST /v1/bank/settlements/import
{
  "bankAccountId": "…",
  "provider": "stripe",
  "content": "balance_transaction_id,created_utc,…,reporting_category,…,automatic_payout_id,…"
}

इम्पोर्ट व्यवहार:

पंक्तियों को automatic_payout_id द्वारा निपटान बैचों (settlement batches) में समूहीकृत किया जाता है - प्रति भुगतान एक बैच, सकल/शुल्क/शुद्ध कुल (पंक्ति net का योग = वह राशि जो आपके बैंक में पहुँचती है)। किसी भुगतान को फिर से इम्पोर्ट करने को छोड़ दिया जाता है (skipped काउंटर)। जिन पंक्तियों को अभी तक किसी भुगतान के लिए नहीं सौंपा गया है और payout पंक्तियों को छोड़ दिया जाता है और अलग से गिना जाता है।
प्रत्येक चार्ज/रिफंड/विवाद पंक्ति को बिक्री चालान से स्वचालित रूप से मिलाया जाता है (auto-matched), इसके लिए उपयोग किया जाता है: ई-कॉमर्स ऑर्डर का externalRef (order_id, payment_intent_id, source_id, charge_id या किसी भी *_metadata[...] कॉलम से कोई भी मान), उन कॉलम में दिखने वाला चालान fullNumber, और - रिफंड और चार्जबैक के लिए - पहले से मिलाए गए चार्ज का charge_id (समान फ़ाइल या पहले के इम्पोर्ट)।
bank/settlements/list / bank/settlements/get के साथ समीक्षा करें; bank/settlements/match { lineId, invoiceId } (या अनमैच करने के लिए invoiceId: null) के साथ बचे हुए को ठीक करें।

POST /v1/bank/settlements/post { id, date?, commissionPercent? } पूरे बैच को एक संतुलित जर्नल लेन-देन के रूप में पोस्ट करता है और मिलान किए गए चालानों को निपटाता है (paidAmount/paymentStatus, sale_invoice.paid वेबहुक):

शुद्ध भुगतान के लिए बैंक खाते के GL को डेबिट करें; रोके गए शुल्क और शुल्क पंक्तियों के लिए PSP शुल्क (settlements.fees, डिफ़ॉल्ट 6800) को डेबिट करें।
प्रत्येक मिलान किए गए चार्ज के प्रति प्राप्य खाते (accounts receivable) को क्रेडिट करें; रिफंड और चार्जबैक इसे उलट देते हैं। आवेदन प्रत्येक चालान की शेष राशि तक सीमित है - कोई भी अतिरिक्त राशि चेतावनी के साथ सस्पेंस खाते पर उतरती है।
बेजोड़ शुल्क: commissionPercent सेट होने पर उन्हें आयोग राजस्व (settlements.commissionRevenue, डिफ़ॉल्ट 5001) और विक्रेता देयता (settlements.sellerPayable, डिफ़ॉल्ट 4499) में विभाजित किया जाता है - बाज़ार प्रवाह जहाँ एकत्र किया गया धन ज्यादातर विक्रेताओं का होता है। इसके बिना उन्हें settlements.suspense (डिफ़ॉल्ट 4440, प्राप्त अग्रिम) पर पार्क किया जाता है।
platform_earning पंक्तियाँ (Stripe Connect एप्लिकेशन शुल्क) आयोग राजस्व में पोस्ट होती हैं; transfer पंक्तियाँ (जुड़े हुए विक्रेताओं को भुगतान) विक्रेता देयता को कम करती हैं।
पोस्टिंग नियमों (ledger/posting-rules) के माध्यम से प्रति कंपनी सभी चार खातों को ओवरराइड किया जा सकता है।
एक ऐसी पंक्ति जिसके चार्ज, शुल्क या रिफंड को Stripe भुगतान निर्यात (bank/statements/import) से किसी अन्य बैंक खाते पर पहले ही इम्पोर्ट कर लिया गया है, उसे शुल्क, प्राप्य या सस्पेंस पर बुक नहीं किया जाता है। इसके बजाय इसके net को उस बैंक खाते के लेज़र खाते में क्रेडिट किया जाता है, ताकि Stripe बैंक खाता भुगतान-दर-भुगतान साफ़ हो जाए। summary.clearedAmount इस तरह से ले जाया गया कुल योग है; जिस पंक्ति की राशि उस खाते के पास मौजूद राशि से भिन्न है, उसका नाम warnings में है। यदि बुक करने के लिए कुछ नहीं बचा है, तो बैच को journalTransactionId null के साथ पोस्ट किया जाता है।

bank/settlements/list और /get प्रति बैच, clearedNet, clearingDifference (भुगतान पंक्तियाँ माइनस अन्य बैंक खाता उनके लिए रखता है; जब वे सहमत होते हैं तो शून्य) और clearingOpenCount (अंतर या अपोस्टेड गतिविधि वाली पंक्तियाँ) लौटाते हैं; /get प्रति पंक्ति clearingBankAccountId, clearingBooked, clearingDifference और clearingUnposted के रूप में समान लौटाता है। एक चार्ज की रिफंड लाइनों की एक साथ तुलना की जाती है, क्योंकि भुगतान निर्यात में केवल रिफ़ंड किया गया कुल योग होता है। भुगतान पोस्ट होने के बाद इम्पोर्ट किया गया Stripe भुगतान निर्यात उस भुगतान की गतिविधियों को छोड़ देता है और इसे warnings में नामित करता है।

आयोग पर वैट का चालान अलग से जारी किया जाता है (विक्रेता को आयोग चालान जारी करें); विभाजन केवल एकत्र किए गए नकद को आवंटित करता है।

किसी अन्य मुद्रा में भुगतान

जर्नल हमेशा कंपनी की आधार मुद्रा में लिखा जाता है, लेकिन एक अलग मुद्रा में भुगतान अपने आप पोस्ट हो जाता है - किसी मैन्युअल प्रविष्टि की आवश्यकता नहीं होती है:

बैच पोस्टिंग तिथि (date, भुगतान तिथि पर वापस गिरते हुए, फिर आज) के लिए दर पर परिवर्तित होता है। दर उस मुद्रा के लिए कंपनी की अपनी दर है (reference/exchange-rates/set) जब यह आधिकारिक दर जितनी कम से कम हाल ही में हो, अन्यथा उस तिथि पर या उससे पहले नवीनतम आधिकारिक दर। उस तिथि पर या उससे पहले किसी दर के बिना कॉल 422 के साथ विफल हो जाती है और reference/exchange-rates/sync का नाम देती है।
प्रत्येक खाता उस बैच दर पर परिवर्तित होता है सिवाय प्राप्य खातों (accounts receivable) के, जिन्हें उस fxRate पर राहत मिलती है जिस पर प्रत्येक चालान जारी किया गया था। दो दरों के बीच का अवशिष्ट (residual) एक महसूस किए गए विनिमय अंतर के रूप में bank.fxGain (डिफ़ॉल्ट 5803) या bank.fxLoss (डिफ़ॉल्ट 6803) में पोस्ट होता है, ताकि जर्नल अभी भी संतुलित रहे।
प्रतिक्रिया summary उपयोग की जाने वाली fxRate और परिणामी exchangeDifference लौटाती है, और बैच उस दर को रखता है जिस पर इसे पोस्ट किया गया था। एक मिलान किया गया चालान जिसकी अपनी मुद्रा बैच मुद्रा से भिन्न है, उसका निपटान नहीं किया जाता है: इसकी राशि चेतावनी के साथ सस्पेंस खाते में जाती है।
एक इम्पोर्ट सीमा बनी रहती है: एक एकल भुगतान जिसकी पंक्तियाँ कई मुद्राओं को मिलाती हैं, उसे 422 के साथ अस्वीकार कर दिया जाता है, जैसा कि एक पुनः-इम्पोर्ट है जिसकी मुद्रा उस भुगतान के लिए पहले से संग्रहीत बैच से भिन्न है।

मैन्युअल / कस्टम फ़ीड

कुछ भी अन्य सादे JSON के रूप में पुश किया जा सकता है:

POST /v1/bank/transactions/import
{
  "bankAccountId": "…",
  "transactions": [
    { "date": "2026-07-01", "amount": "-25.00", "currency": "EUR",
      "counterpartyName": "…", "description": "…", "externalId": "unique-ref-1" }
  ]
}

पुनः इम्पोर्ट को idempotent रखने के लिए प्रति लेन-देन एक स्थिर externalId प्रदान करें।