카드 결제는 이미 주문을 명시하고 있는 acquirer 보고서를 통해 장부에 도달합니다. USDC 송금은 주소, 금액, 트랜잭션 해시만 가지고 도착하며 그 밖의 정보는 없습니다. 송금에는 사업 참조 번호가 없으므로, 암호화폐 결제 대사는 인보이스에 그 번호가 포함되어 있을 때 작동합니다.
이 가이드는 스테이블코인을 받아 유로로 정산하는 가맹점, PSP, EMI의 재무 및 운영 팀을 위한 것입니다. 각 인보이스 기록에 필요한 필드, 부분 결제와 잘못된 코인 결제의 처리 방법, 웹훅과 API가 원장에 데이터를 전달하는 방식, 그리고 이 모든 기록을 얼마나 오래 보관해야 하는지 정하는 EU 규칙을 정리합니다.
주요 장면
요약
- ERC-20 송금에는 발신자, 수신자, 금액만 담겨 있습니다. 주문 참조 번호는 결제 자체가 아니라 인보이스에 있어야 합니다.
- 인보이스 가격은 EUR로 책정하고 그 유로 금액을 장부에 기록하세요. 암호화폐 금액은 감사 추적을 위해 보관하는 파생 수치입니다.
- 작업의 대부분은 예외 처리에 있습니다. 부분 결제, 만료된 인보이스, 잘못된 코인이 여기에 해당합니다. 월말이 아니라 매일 검토하세요.
- 웹훅을 트리거로 사용하고, ID로 인보이스를 다시 조회해 기준 정보로 삼으세요. 그리고 인보이스 목록을 매일 밤 가져와 안전망이자 CSV 내보내기의 원천으로 활용하세요.
암호화폐 결제 대사가 카드보다 어려운 이유는 무엇인가요?#
블록체인 송금에는 주문번호를 담을 필드가 없기 때문에 암호화폐 결제 대사가 더 어렵습니다. 이더리움에서 ERC-20 토큰 표준(EIP-20)은 송금 이벤트를 `Transfer(address _from, address _to, uint256 _value)`로 정의합니다. 누가 보냈는지, 누가 받았는지, 얼마인지만 담깁니다. 메모도, 인보이스 번호도, 고객 이름도 없습니다.
은행 및 카드 결제는 반대 방식으로 설계되어 있습니다. SEPA 송금에는 송금인이 입력하는 송금 정보 필드가 있고, acquirer의 정산 보고서는 각 카드 거래를 가맹점 참조 번호와 함께 나열합니다. 회계 시스템은 그 참조 번호로 매칭합니다.
스테이블코인에서는 세 가지 문제가 더 있습니다:
- 금액이 딱 떨어지는 경우가 드뭅니다. USDC로 환산된 250 EUR 인보이스는 279.2846 USDC 같은 수치가 되므로, 규모가 비슷한 인보이스 두 건이 겉보기에 비슷해 보일 수 있습니다.
- 결제가 즉시 확정되지는 않습니다. 이더리움은 12초마다 블록을 생성하지만, ethereum.org(2026년 10월 업데이트 페이지)에 따르면 “이더리움 블록이 확정되는 데 약 15분이 걸립니다.” 송금이 보이더라도 아직 인정되지 않을 수 있습니다.
- 결제자는 실수를 합니다. 금액을 적게 보내거나, 두 번 보내거나, 다른 코인을 보내거나, 인보이스가 만료된 뒤에 결제합니다.
따라서 연결 고리는 결제자가 돈을 보내기 전에 이미 존재해야 합니다. 주문 하나당 인보이스 하나를 만들고, 주문 ID와 고유 결제 주소를 담으세요. 그래야 들어오는 송금마다 무엇을 위한 것인지 이미 알고 있는 기록에 도달합니다.
각 암호화폐 인보이스 기록에는 어떤 필드가 필요한가요?#
모든 인보이스에는 주문, 유로 가격, 온체인 송금, 최종 상태 네 가지를 묶는 고정된 필드 세트가 필요합니다. 하나라도 빠지면 누군가가 수작업으로 매칭하게 됩니다. 아래 표는 ItisPay 인보이스 API의 필드명을 사용합니다. 다른 제공업체는 같은 개념에 다른 이름을 사용할 수 있습니다.
| 필드 | 담고 있는 내용 | 회계에 필요한 이유 |
|---|---|---|
| invoice_id | 제공업체가 할당하는 고유 ID | 모든 조회와 모든 원장 행의 기본 키 |
| order_id | 주문 또는 계약 번호, 주문별로 고유 | ERP, 쇼핑몰 또는 CRM과의 연결 고리. 카드가 무료로 제공하는 참조 번호 |
| order_name | 주문에 대한 짧은 설명 | 쇼핑몰을 열지 않고도 사람이 예외를 확인할 수 있게 함 |
| fiat_amount, fiat_currency | EUR 가격 | 장부에 기록하는 매출 금액 |
| currency, crypto_amount | 청구한 코인과 청구 금액 | 결제자에게 요청한 송금액을 보여줌 |
| actual_crypto_amount_paid | 실제로 도착한 금액 | 과소 결제와 초과 결제를 감지함 |
| currency_paid | 사용한 코인(청구한 코인과 다른 경우) | 잘못된 코인 결제를 검토 대상으로 표시함 |
| network, address | 블록체인 네트워크와 결제 주소 | 돈이 어디로 보내졌는지 증명하며, 추적이나 환불에 필요함 |
| transactions (tx_hash, amount, status) | 들어오는 송금 건당 한 줄 | 하나의 인보이스가 여러 송금을 받을 수 있으며, 각 해시가 온체인 증빙임 |
| status | new, pending, completed, expired, cancelled, paid_partial | 장부 기입, 배송, 추심, 종결 중 무엇을 할지 결정함 |
| created_at, updated_at, expires_at | 타임스탬프 | 월말 마감 기준과 주문이 결제된 시점의 증빙 |
이 중 두 가지가 대부분의 역할을 합니다. `order_id`는 블록체인 송금이 담을 수 없는 참조 번호이므로, 자체 시스템에서 설정하고 고객별이 아닌 주문별로 고유하게 만드세요. `transactions` 목록도 중요합니다. 인보이스는 한 번에 결제되지 않는 경우가 많기 때문입니다. 각 송금은 해시와 상태를 가진 자체 행을 얻으므로, 결제된 금액을 어떤 송금들이 구성하는지 확인할 수 있습니다.
암호화폐 금액은 모든 소수점 자리와 함께 별도 열에 저장하세요. 총계정원장은 유로 센트 단위로 작동하며, 암호화폐 열은 장부 금액이 아니라 증빙입니다.
장부에는 어떤 유로 금액을 기록해야 할까?#
인보이스에 적힌 유로 가격을 기록하세요. 인보이스가 EUR로 발행되면 제공업체가 현재 환율로 이를 암호화폐 금액으로 환산하고, 결제자는 그 금액을 송금합니다. 결제가 계정에서 유로로 정산되면, 인보이스의 유로 금액이 수익이며 암호화폐 금액은 자금이 입금된 방식에 대한 기술적 세부사항일 뿐입니다.
이것이 EUR 환전과 함께 암호화폐 결제를 자동으로 수취하는 방법을 사용하는 팀이 암호화폐 회계를 거의 필요로 하지 않는 주된 이유입니다. 월말에 평가할 코인이 재무상태표에 남지 않기 때문입니다.
스테이블코인을 보유한다면 이야기가 달라집니다. IFRS 해석위원회는 2019년 6월, 암호화폐 보유자산이 통상적인 영업 과정에서 판매 목적으로 보유될 경우 IAS 2(재고자산)에, 그렇지 않은 경우 IAS 38(무형자산)에 해당한다고 결정했습니다. 해당 위원회의 암호화폐 정의에서는 보유자와 다른 당사자 사이에 계약을 발생시키는 자산은 제외됩니다. USDC는 다릅니다. Circle은 USDC가 “미국 달러로 1:1 상환 가능하다”고 밝혔으며, 2024년 7월부터 Circle은 프랑스 규제당국 ACPR로부터 받은 전자화폐 라이선스에 따라 EU에서 USDC와 EURC를 전자화폐 토큰(e-money token)으로 발행하고 있습니다. 보유 스테이블코인을 어떻게 분류할지는 감사인과 상의해야 할 문제입니다. 수령 시점에 EUR로 정산하면 이 문제는 발생하지 않습니다.
부분 결제와 잘못된 코인은 어떻게 처리하나요?#
`completed`가 아닌 모든 인보이스는 담당자와 기한이 정해진 예외 건으로 처리하세요. 암호화폐 결제 대사 작업의 대부분이 여기서 발생합니다. 전액 결제된 인보이스는 스스로 대사됩니다.
ItisPay 상태값 기준으로, 각 상태가 재무 측면에서 무엇을 의미하는지 정리하면 다음과 같습니다:
| 상태 | 발생한 일 | 재무팀이 할 일 | 출하 또는 해제? |
|---|---|---|---|
| new | 인보이스 개방, 입금 없음 | 기록할 것 없음 | 아니오 |
| pending | 송금이 확인되었으나 아직 확정되지 않음 | 상태 변경 대기 | 아니오 |
| completed | 전액 결제 완료 | EUR 가격으로 수익 기록, 주문 해제 | 예 |
| paid_partial | 금액 일부가 입금됨 | 잔액 요청, 환불, 또는 합의 후 종료 | 상황에 따라 |
| expired | 전액 결제 없이 시간 초과 | 주문 종료; 지연 송금 여부 확인 | 아니오 |
| cancelled | 인보이스를 취소함 | 기록 없음; 고객이 여전히 결제를 원하면 재발행 | 아니오 |
부분 결제#
부분 결제는 보통 결제자의 지갑이나 거래소가 금액에서 수수료를 떼었거나, 결제자가 금액을 잘못 입력했음을 의미합니다. ItisPay는 각 송금을 개별적으로 기록하므로, 두 번째 송금으로 인보이스가 완료될 수 있습니다. 인보이스에는 `allowed_error_percent` 설정도 있습니다. 이는 인보이스별로 지정하는 소액의 허용 오차로, 약간 부족한 결제도 완료된 것으로 인정할 수 있게 합니다. 예를 들어 은행 송금에서도 손실로 처리할 수 있는 수준으로 한 번 정책을 설정하고, 건마다 바꾸지 마세요.
나머지 금액이 끝내 도착하지 않으면 정해진 일수 내에 결정하세요. 부족분을 인정하고 손실 처리하거나, 입금된 금액을 환불하거나, 주문을 취소합니다. 결제 완료 주문에 실제로 받은 금액이 적은 이유를 감사인이 알 수 있도록 인보이스 기록에 결정 내용을 남기세요.
잘못된 코인 또는 지연 결제#
결제자가 인보이스에 기재된 것과 다른 스테이블코인을 보내면 `currency_paid` 필드에 표시됩니다. 자동으로 기록하지 마세요. 금액과 유로 환산 가치를 확인한 뒤 수락하거나 환불하세요. 만료된 인보이스로의 송금도 비슷합니다. 자금은 온체인에 있지만 주문은 이미 종료되었으므로, 주문을 다시 열지 아니면 자금을 반환할지 누군가 결정해야 합니다. 자사 측에서 주문을 무효화했다면, 지연 결제가 도착하기 전에 API를 통해 인보이스를 취소(상태 업데이트)하세요. 그래야 기록에 종료된 것으로 표시됩니다.
웹훅과 API는 암호화폐 결제 대사를 어떻게 뒷받침하나요?#
세 개의 계층을 사용하세요. 웹훅은 무언가 변경되었다는 것을 알려주고, 인보이스를 새로 조회하면 실제 상태를 확인할 수 있으며, 매일 밤 모든 인보이스를 가져오면 앞의 두 단계가 놓친 것을 잡아냅니다.
- 각 인보이스에는 `callback_url`을 지정할 수 있으며, 제공업체는 그 주소로 상태 업데이트를 보냅니다. 메시지를 증명이 아닌 트리거로 취급하세요.
- 웹훅을 받을 때마다 `GET /invoices/{invoice_id}`를 호출하고, 응답에 담긴 상태와 금액을 기준으로 처리하세요. API 호출에는 API 키가 필요하므로, 엔드포인트에 대한 위조되거나 재전송된 호출로부터 보호됩니다.
- 핸들러를 멱등하게 만드세요. 같은 상태가 두 번 도착할 수 있습니다. 원장 항목을 `invoice_id`와 상태의 조합으로 식별하면, 반복 수신 시 아무것도 바뀌지 않습니다.
- 매일 밤 `updated_at` 기준 최신순으로 인보이스 목록을 가져오고, 마지막 실행 시점까지 페이지를 거슬러 조회하세요. 또한 여전히 `new`, `pending`, `paid_partial` 상태인 모든 인보이스를 다시 확인하세요. 원장과 비교했을 때 제공업체 기록에서는 결제되었지만 자사 원장에서는 열려 있는 항목은 예외 건입니다.
테스트를 위해 ItisPay에는 인보이스의 상태 변경을 시뮬레이션하는 엔드포인트와, `invoice_id` 또는 `order_id`로 최신 웹훅을 다시 전송하는 엔드포인트가 있습니다. 서버가 다운되었을 때는 재전송을 사용하세요. 여러 결제 수단을 하나의 결제 오케스트레이션 계층을 통해 처리하는 팀은 모든 결제 경로에 같은 패턴을 적용합니다.
회계용 CSV 내보내기는 어떻게 만드나요?#
청구서 목록 API로 내보내기를 만드세요. 청구서 한 건당 한 행, 이체 한 건당 한 행을 씁니다. ItisPay의 `GET /invoices`는 상태, 코인, 생성일로 필터링하고, 날짜나 금액으로 정렬하며, 페이지 수와 함께 페이지당 최대 100건의 청구서를 반환합니다. 작은 스크립트로 하루나 한 달 동안의 페이지를 순회하며 위 필드 표의 열에 맞춰 값을 쓰면 됩니다.
파일은 하나보다 두 개가 더 편리합니다:
- `invoices.csv`: invoice_id, order_id, fiat_amount, fiat_currency, currency, crypto_amount, actual_crypto_amount_paid, status, created_at, updated_at. 회계 담당자가 가져와 매출과 대조하는 파일입니다.
- `transfers.csv`: invoice_id, tx_hash, amount, currency, transfer status, time. 감사인을 위한 증빙 파일입니다.
청구서 파일은 카드 정산 보고서를 가져오듯 회계 도구에 가져오세요: 주문당 한 줄, 유로 금액, 매칭 키는 주문 ID입니다.
암호자산 결제 기록에는 어떤 EU 규정이 적용되나요?#
세 가지 EU 규정이 배경이 됩니다. 어느 것도 가맹점을 암호자산 서비스 제공자(CASP)로 만들지는 않지만, 어떤 데이터가 존재하고 얼마나 오래 보관해야 하는지를 정합니다.
- 자금이체규정(Transfer of Funds Regulation) (EU) 2023/1113. 2024년 12월 30일부터 지급인의 암호자산 서비스 제공자는 각 이체에 지급인과 수취인에 대한 정보가 동반되도록 해야 합니다(예: 이름과 원장 주소, 제14조). 이 데이터는 이체 내부가 아니라 이체와 함께 전달됩니다. 자가 관리 지갑(self-hosted wallet)으로 또는 그로부터 이루어지는 1,000유로 초과 이체의 경우, 해당 측 제공자는 그 지갑이 자사 고객의 것인지 평가해야 합니다(제14조 및 제16조). 이는 인가받은 제공자의 업무이며, 결제가 검토 상태에 머무를 수 있는 이유 중 하나입니다.
- 기록 보관. 현행 AML 지침(EU) 2015/849 제40조에 따라 의무 대상 기관은 거래 기록을 사업 관계가 끝나거나 거래가 이루어진 후 5년간 보관합니다. 새 AML 규정(EU) 2024/1624는 5년 기간을 유지하며(제77조), 2027년 7월 10일부터 적용됩니다.
- DAC8, 지침(EU) 2023/2226. 2026년 1월 1일부터 암호자산 서비스 제공자는 이용자의 암호자산 거래를 세무 당국에 보고합니다. 자체 기록은 제공자가 보고하는 내용과 일치해야 합니다.
인가받은 파트너를 통해 거래하는 경우, 우리 가이드 MiCA CASP 라이선스에서 설명한 대로 파트너가 MiCA와 이 규정들에 따른 CASP 의무를 집니다. 그래도 주문 기록과 귀사 측 추적 기록은 직접 보관해야 합니다.
암호자산 정산 대사에서 여전히 사람이 필요한 부분은 어디인가요?#
자동화는 전액 지급된 경우를 처리합니다. 나머지에는 담당자 한 명과 짧은 서면 정책이 필요합니다.
도움이 되지 않는 경우
- 환불은 취소가 아니라 새로운 송금입니다. 주소나 IBAN으로의 지급과 별도의 기록이 필요합니다.
- 거래소 계정에서 송금하는 지급인은 발신 주소로 항상 식별되지는 않습니다. 발신인이 아니라 청구서를 기준으로 매칭하세요.
- 만료된 청구서로의 지급, 중복 지급, 잘못된 코인은 모두 사람의 판단이 필요합니다.
- 네트워크 수수료와 반올림으로 작은 차이가 생깁니다. 허용 오차를 한 번 정하고 일관되게 적용하세요.
5단계로 보는 일일 암호화폐 결제 대사 루틴#
짧은 일일 루틴을 지키면 월말 마감은 형식적인 절차에 그칩니다:
- 마지막 실행 이후 생성되거나 업데이트된 청구서를 API에서 가져와 청구서 및 이체 파일을 갱신합니다.
- 모든 `completed` 청구서에 쇼핑몰이나 ERP의 결제 완료 주문이 대응되는지, 그 반대도 확인합니다.
- 예외 목록을 처리합니다: `paid_partial`, 만료된 청구서로의 지급, 잘못된 코인. 각 건은 서면 결정으로 종결합니다.
- 은행 계좌의 유로 정산 금액을 기간 내 완료된 청구서 합계와 대조합니다. IBAN으로의 정산은 가상 IBAN이 사업 라인별로 흐름을 분리하는 데 도움이 되는 지점입니다.
- 두 파일을 최소 5년간 보관합니다.
이 스택을 직접 구축하지 않고 스테이블코인을 받아 유로로 정산받으려면, ItisPay가 API, 청구서 발행, 대사 데이터를 제공합니다: 청구서 및 주문 ID, 이체별 해시, 상태, 웹훅. 라이선스, KYC, IBAN으로의 정산은 EU 인가 CASP + 지급결제기관 파트너를 통해 진행되며, 대부분의 팀은 KYB 단계에서 첫 거래까지 일주일 미만이 걸립니다.
이 글은 정보 제공 목적으로만 작성되었으며 법률 또는 규제 자문을 구성하지 않습니다.
