암호 감사 소프트웨어: 독일의 회계 및 감사 요구사항 충족

독일은 유럽에서 재무 보고에 가장 까다로운 관할권 중 하나이며, 암호화폐 자산도 이러한 검토에서 예외가 아닙니다. 중형 펀드의 대차대조표를 승인하는 감사관, 암호화폐 네이티브 기업의 재무팀, 또는 디지털 자산을 보유한 고객에게 조언하는 회계 법인 등, 규칙은 명확합니다. 독일 상법이 적용되며 정확하게 적용됩니다. 적절한 암호화폐 감사 소프트웨어는 더 이상 편의를 위한 것이 아니라 규제 검토를 견딜 수 있는 장부를 작성하기 위한 전제 조건입니다. 이 글에서는 독일 법률이 실제로 요구하는 사항, 이러한 요구사항이 실질적인 시스템 기능으로 어떻게 전환되는지, 그리고 기업과 감사관이 작업을 제대로 수행하기 위한 도구를 선택할 때 무엇을 찾아야 하는지 설명합니다.

독일이 암호화폐 회계 시스템에 더 많은 것을 요구하는 이유

독일의 회계 프레임워크는 상법전(Handelsgesetzbuch, HGB)에 기반을 두고 있습니다. 상장 기업의 연결 보고를 규율하는 IFRS와 달리, HGB는 GmbH, AG, 파트너십 등 다양한 법인 유형의 개별 재무제표를 규율합니다. HGB는 암호화폐를 염두에 두고 작성되지 않았지만, 독일 회계 실무는 일반 원칙을 디지털 자산에 상당한 엄격함으로 적용해 왔습니다.

HGB에 따르면, 핵심 원칙인 신중성 원칙(Vorsichtsprinzip)은 미실현 이익은 인식하지 않고 미실현 손실은 인식하도록 요구합니다. 암호화폐 보유의 경우, 이는 다른 관할권에서 사용되는 공정 가치 모델과 근본적으로 다른 비대칭적 회계 처리를 만듭니다. 취득 이후 가치가 상승한 비트코인을 보유한 회사는 그 이익을 장부에 반영할 수 없습니다. 가치가 취득 원가 아래로 떨어진 경우 손상차손을 기록해야 합니다. 이 보수적인 접근 방식은 회계 시스템이 각 자산 로트의 최초 취득 원가를 추적하고, 시장 가치를 지속적으로 모니터링하며, 수동 개입 없이 손상 의무를 플래그할 수 있어야 함을 요구합니다.

질서 있는 장부 기록 원칙(Grundsätze ordnungsmäßiger Buchführung, GoB)은 완전성, 정확성, 적시성, 추적 가능성에 대한 추가 요구사항을 추가합니다. 모든 암호화폐 거래는 완전히 기록되어야 하며, 원천 데이터에 연결되고, 제3자 감사관이 재구성할 수 있어야 합니다. 원시 거래소 또는 지갑 데이터에서 최종 장부 항목까지 끊김 없는 체인을 입증할 수 없는 시스템은 독일 법정 감사를 통과할 수 없습니다.

암호화폐 감사 소프트웨어가 HGB 준수 보고를 지원하는 방법

독일 시장을 위해 설계된 암호화폐 감사 소프트웨어는 일반적인 부기 플랫폼으로는 처리할 수 없는 여러 작업을 처리해야 합니다. 첫째는 로트 수준의 원가 기준 추적입니다. 독일 세법과 상법 모두 특정 식별법과 FIFO를 유효한 방법으로 인정하지만, 기업이 어떤 방법을 적용하든 일관되게 적용하고 완전히 문서화해야 합니다. 유능한 시스템은 취득 일자, 유로화 취득 가격, 거래소 또는 지갑 출처를 포함하여 취득된 모든 로트에 대한 개별 기록을 유지해야 합니다.

두 번째 요구사항은 자동화된 손상 검사입니다. HGB는 유동자산으로 보유된 암호화폐 자산을 대차대조표일 기준으로 원가와 시가 중 낮은 금액으로 평가절하해야 하므로, 소프트웨어는 보고일 기준 신뢰할 수 있는 시장 가격을 가져와 각 미결제 로트의 장부 금액과 비교하고 손상 일정을 생성할 수 있어야 합니다. 이는 의미 있는 규모에서 수동 작업이 아닙니다. 잠재적으로 수천 개의 포지션에 걸쳐 체계적인 처리가 필요합니다.

아래 표는 회계사와 감사관을 위한 암호화폐 회계가 시스템 수준에서 처리해야 하는 주요 HGB 요구사항을 요약합니다.

HGB 요구사항	회계 원칙	필요한 시스템 기능
신중성 원칙(Vorsichtsprinzip)	손실 인식, 미실현 이익은 인식하지 않음	보고일 기준 로트별 자동 손상 검사
역사적 원가 기준	자산은 취득 원가로 계상	취득 일자 및 가격 포함 로트 수준 원가 추적
완전성(Vollständigkeit)	모든 거래 기록	전체 거래소 및 지갑 API 수집, 갭 탐지 포함
추적 가능성(Nachvollziehbarkeit)	감사 추적 제3자 재구성 가능	원천 데이터에 연결된 불변 거래 로그
일관성 원칙	동일한 방법 매년 적용	방법 잠금 및 감사관 접근 가능 변경 로그

감사관이 구체적으로 필요로 하는 것: 감사관을 위한 암호화폐 회계

감사관은 고객의 암호화폐 보유를 검토할 때 뚜렷한 문제에 직면합니다. 기본 감사 증명(존재, 완전성, 평가, 권리와 의무) 모두 전통적인 확인을 통해 얻을 수 없는 증거가 필요합니다. 은행은 고객의 비트코인을 보유하지 않습니다. 블록체인이 보유하며, 이는 감사관이 온체인 확인, 지갑 소유권 증명, 거래소 수탁 약정을 이해해야 함을 의미합니다.

따라서 감사관을 위한 암호화폐 회계는 관리 회계뿐 아니라 감사관 친화적인 출력을 생성할 수 있는 소프트웨어를 필요로 합니다. 이는 각 대차대조표 포지션을 특정 블록체인 주소 또는 거래소 계정으로 매핑하는 내보내기 가능한 작업 파일, 고객의 총계정원장과 일치하는 타임스탬프가 찍힌 거래 내역, 온체인 데이터와 기록된 금액 사이의 설명되지 않은 차이를 식별하는 조정 보고서를 의미합니다.

독일 감사인이 고려해야 할 추가 사항은 Wirtschaftsprüferordnung에 따라 새로운 자산군에 대해 회의적 관점을 유지해야 한다는 요구사항입니다. 디지털 자산은 독일 회계사 협회(IDW)의 지침에서 강화된 절차가 필요한 항목으로 구체적으로 명시되어 있습니다. IDW 회계 기준 RS HFA 50은 암호자산의 회계 처리를 다루며, 이러한 포지션과 관련된 모든 감사 계약은 이 기준에 따라 평가되어야 합니다. RS HFA 50 요구사항에 부합하는 결과물을 생성하는 소프트웨어는 감사인이 실질적 절차에 소요하는 시간을 크게 줄여줍니다.

회계 법인을 위한 암호회계: 클라이언트 간 확장

암호자산을 보유한 여러 클라이언트를 관리하는 회계 법인의 경우, 과제는 기술적 정확성뿐만 아니라 운영 확장성입니다. 각각 활성 암호자산 포트폴리오를 가진 10명의 클라이언트를 관리하는 파트너는 각각에 대해 수동 조정을 수행할 여유가 없습니다. 회계 법인을 위한 암호회계는 각 클라이언트의 데이터가 명확히 분리되고, 접근 제어가 세분화되며, 매번 프로세스를 처음부터 다시 구축하지 않고도 모든 계약에서 일관된 결과물을 생성할 수 있는 다중 엔터티 아키텍처를 필요로 합니다.

아래 표는 일반적인 법인 수준 요구사항과 잘 설계된 암호감사 소프트웨어 플랫폼이 이를 어떻게 해결하는지 보여줍니다.

법인 요구사항	중요성	필요한 플랫폼 기능
다중 클라이언트 관리	각 클라이언트는 분리된 데이터와 보고가 필요함	역할 기반 접근이 가능한 별도 엔터티 작업 공간
일관된 방법론	법인은 모든 계약에 동일한 기준을 적용해야 함	원가 기준법 및 손상에 대한 법인 전체 설정 템플릿
규제 기관을 위한 감사 추적	법인은 클라이언트 계정의 정확성에 대해 책임 있음	법인과 감사인 모두가 접근 가능한 불변 로그
거래소 및 지갑 통합	수동 데이터 입력은 오류와 규정 준수 격차를 만듦	주요 거래소 및 지갑 제공업체와의 API 연결
독일 GAAP 출력	HGB 보고는 IFRS 및 US GAAP 출력과 다름	구성 가능한 계정과목표 및 손상 일정

목적에 맞게 구축된 회계 법인용 암호회계에 투자하는 법인은 계약 위험을 줄이고, 데이터 수집에서 서명된 계정까지의 시간을 단축하며, 암호회계를 공식 서비스 라인으로 제공할 수 있는 더 나은 위치에 서게 됩니다. 이 작업의 규정 준수 보고 측면에 대한 소개는 CryptaCount 플랫폼의 법인을 위한 암호 규정 준수 보고 섹션을 참조하십시오.

펀드를 위한 암호회계: 추가 복잡성

암호 펀드와 투자 수단은 표준 상업 회계를 넘어서는 보고 요구사항에 직면합니다. 투자자를 대신해 암호자산을 보유하는 펀드는 포지션 수준까지 정확한 순자산가치 계산, 배분 일정 및 투자자 명세서를 생성해야 합니다. 따라서 암호 펀드 회계 소프트웨어는 기초 자산의 HGB 또는 IFRS 처리를 처리할 뿐만 아니라 성과 수수료, 균등화 및 주식 클래스 NAV와 같은 펀드별 계산도 처리해야 합니다.

Kapitalanlagegesetzbuch(KAGB)에 따른 구조를 포함한 독일 규제 펀드 구조는 BaFin의 감독을 받습니다. BaFin은 암호 노출이 있는 펀드가 전통 증권을 보유한 펀드와 동일한 수준의 기록 보관 및 평가 문서화 기준을 유지해야 한다는 지침을 발표했습니다. 이는 암호 펀드 회계 소프트웨어가 BaFin이 임명한 예탁 은행이 독립적으로 검증할 수 있는 평가 보고서를 생성할 수 있어야 함을 의미합니다. 온체인 소스 데이터에서 감사된 NAV 수치까지 모든 포지션을 추적할 수 있는 능력은 선택 사항이 아니라 규제 기대치입니다.

암호 할당이 있는 대체 투자 펀드 및 패밀리 오피스에도 동일한 논리가 적용됩니다. 이러한 구조를 지원하는 암호 회계사는 복잡한 소유 구조, 여러 체인에 걸친 여러 지갑, 그리고 다른 보고 대상에 대해 다른 회계 프레임워크에서 포지션을 재작성할 수 있는 도구가 필요합니다.

암호 감사 소프트웨어 선택: 독일 계약을 위한 주요 기준

암호 감사 소프트웨어로 마케팅되는 모든 플랫폼이 독일 법정 요구사항을 염두에 두고 구축된 것은 아닙니다. 많은 플랫폼이 주로 미국 세무 보고 또는 IFRS 공정가치 회계를 위해 설계되었으며, 어느 것도 HGB에 깔끔하게 매핑되지 않습니다. 독일 대상 계약을 위한 옵션을 평가할 때 다음 기준은 필수적입니다.

첫째, 플랫폼은 HGB에서 요구하는 원가-시가 중 낮은 가격으로 평가하는 손상 모델을 지원해야 합니다. 시가평가 또는 공정가치 회계만 지원하는 플랫폼은 수동 조정 없이는 독일 법정 계정에 사용할 수 없는 수치를 생성하므로 자동화 목적에 어긋납니다.

둘째, 플랫폼은 GoB 추적 요구사항을 충족하는 완전한 감사 추적을 제공해야 합니다. 모든 거래에는 타임스탬프, 출처 및 기본 데이터에 대한 링크가 있어야 합니다. 기록된 데이터의 모든 수정은 자체적으로 기록되어야 하며, 원래 항목이 보존되어야 합니다. 이는 모든 법정 감사 계약에서 필수불가결합니다.

셋째, 플랫폼은 IDW RS HFA 50 출력 형식을 지원하거나 최소한 해당 표준에 익숙한 감사인이 쉽게 사용할 수 있는 구조로 데이터를 생성해야 합니다. 넷째, 회계 법인에게 다중 엔터티 지원이 필수적입니다. 다섯째, 플랫폼은 독일 기관 클라이언트가 가장 일반적으로 사용하는 거래소 및 수탁업체(주요 유럽 거래소 및 규제된 독일 수탁업체 포함)와의 통합이 확립되어 있어야 합니다.

예시 시나리오

이것이 실제로 어떻게 적용되는지 설명하기 위해 다음 시나리오를 고려하십시오:

마르쿠스는 프랑크푸르트에 있는 중견 감사 회사의 Wirtschaftsprüfer(공인회계사)입니다. 그의 오랜 고객 중 하나인 핀테크 분야의 GmbH가 재무부의 상당 부분을 두 개의 거래소와 하드웨어 지갑에 걸쳐 암호 자산으로 보유하기 시작했습니다. 연말 감사가 다가오고 있으며, 마르쿠스는 존재 여부를 확인하고, 기록된 거래의 완전성을 확인하며, HGB의 신중주의 원칙에 따라 손상이 올바르게 적용되었는지 확인해야 합니다.

목적에 맞게 설계된 암호 감사 소프트웨어가 없으면, 마르쿠스는 고객에게 거래 내역을 수동으로 요청하고, 이를 총계정원장과 교차 참조하며, 손상 계산을 테스트하기 위해 연말 시장 가격을 독립적으로 조달해야 합니다. 수백 건의 거래에 걸친 이 과정은 며칠이 소요되며 상당한 오류 위험을 수반합니다.

CryptaCount를 사용하면 마르쿠스는 고객 작업 공간에 대한 읽기 전용 감사자 보기에 접근할 수 있습니다. 그는 거래소 API와 온체인 데이터에서 직접 가져온 완전하고 타임스탬프가 찍힌 거래 내역, 각 로트의 장부가액을 대차대조표일 가격과 비교하는 자동화된 손상 일정, 그리고 주요 감사 주장을 뒷받침하도록 구성된 내보내기 가능한 작업 문서 패키지를 볼 수 있습니다. 업무는 효율적으로 완료되고, 출력 결과는 GoB 추적성 요구 사항을 충족하며, 고객의 계정은 확신을 가지고 승인됩니다.

자주 묻는 질문

암호 감사 소프트웨어는 표준 회계 플랫폼이 할 수 없는 무엇을 하나요?

암호 감사 소프트웨어는 블록체인 소스 및 거래소 API에서 직접 거래 데이터를 수집하고, 로트 수준의 원가 기준 기록을 유지하며, 손상 테스트를 자동화하고, 변경 불가능한 감사 추적을 생성합니다. 표준 회계 플랫폼은 수동 데이터 입력이 필요하며, 온체인 존재를 확인하거나 수천 건의 거래에 걸쳐 원가 기준을 자동으로 재구성할 수 없습니다.

암호 자산에 대한 특정 독일 회계 기준이 있나요?

네. Institut der Wirtschaftsprüfer는 IDW RS HFA 50을 발행했으며, 이는 독일 GAAP에 따른 암호 자산의 회계 처리에 대한 지침을 제공합니다. 이는 HGB 재무제표를 작성하는 기업을 위한 분류, 측정 및 공개 요구 사항을 다룹니다. 암호 관련 업무에 종사하는 감사인은 이 기준에 따라 절차를 평가해야 합니다.

HGB에서 암호 자산은 어떻게 평가되어야 하나요?

HGB 신중주의 원칙에 따라, 유동 자산으로 보유된 암호 자산은 취득 원가와 대차대조표일의 시장 가격 중 낮은 금액으로 측정됩니다. 미실현 이익은 인식되지 않습니다. 시장 가격이 원가 아래로 떨어진 경우 손상 차감이 기록되어야 합니다. 이 보수적인 처리 방식은 IFRS의 공정 가치 회계와 크게 다릅니다.

GoB란 무엇이며, 암호 회계에 중요한 이유는 무엇인가요?

Grundsätze ordnungsmäßiger Buchführung(GoB)은 독일의 적절한 부기 원칙입니다. 이는 모든 거래가 완전하고 정확하며 추적 가능한 방식으로 기록되어야 함을 요구합니다. 암호 자산의 경우, 이는 모든 지갑 거래와 거래소 거래가 소스 데이터에 대한 검증 가능한 링크와 함께 기록되어야 하며, 감사인이 독립적으로 회계 기록을 재구성할 수 있어야 함을 의미합니다.

회계 법인은 단일 플랫폼에서 여러 암호 고객을 관리할 수 있나요?

네, 플랫폼이 별도의 고객 작업 공간과 역할 기반 접근 제어를 갖춘 다중 기업 아키텍처를 지원하는 경우 가능합니다. 회계 법인을 위한 암호 회계는 각 고객의 데이터가 완전히 분리되고, 회사 전체의 방법론 설정이 업무 전반에 일관되게 적용될 수 있으며, 감사인이 다른 고객 데이터를 노출하지 않고 읽기 전용 접근 권한을 부여받을 수 있어야 합니다.

독일에서 펀드의 암호 회계에는 어떤 추가 요구 사항이 적용되나요?

KAGB에 따라 규제되는 펀드는 암호를 포함한 모든 자산 클래스에 대해 BaFin의 기록 보관 및 평가 기준을 충족해야 합니다. 이를 위해서는 감사 가능한 NAV 계산, 예치 은행이 확인할 수 있는 포지션 수준 평가 보고서, 그리고 온체인 소스 데이터에서 펀드 계정까지 추적 가능한 전체 거래 내역을 생성할 수 있는 암호 펀드 회계 소프트웨어가 필요합니다.

암호 회계사가 독일 고객을 위해 소프트웨어를 평가할 때 무엇을 찾아야 하나요?

플랫폼은 HGB의 원가 또는 시장 중 낮은 가격 손상 모델을 지원하고, GoB 준수 감사 추적을 유지하며, IDW RS HFA 50에 부합하는 출력을 생성하고, 회사 수준 사용을 위한 다중 기업 관리를 지원해야 합니다. 주요 거래소 및 규제된 독일 수탁자와의 통합도 수동 데이터 처리를 피하고 이로 인한 규정 준수 격차를 방지하는 데 필수적입니다.

감사인은 암호 자산이 실제로 존재하는지 어떻게 확인하나요?

존재는 지갑 소유권 및 온체인 잔액을 확인하여 확인됩니다. 감사인은 일반적으로 개인 키로 서명된 메시지와 같은 지갑 통제 증명을 요청하고, 블록체인 익스플로러를 사용하여 보고일 현재 온체인 잔액을 독립적으로 확인합니다. 기록된 포지션을 특정 지갑 주소 및 블록체인 거래에 연결하는 암호 감사 소프트웨어는 이 절차를 크게 가속화합니다.

독일에서 암호 회계에 IFRS가 적용되나요?

IFRS는 규제 시장에 상장된 독일 기업의 연결 재무제표에 적용됩니다. 대부분의 GmbH 및 비상장 AG를 포함한 개별 법인 재무제표에는 HGB가 적용됩니다. 이 구분은 IFRS와 HGB가 암호 자산을 매우 다르게 취급하기 때문에 중요합니다. 특히 공정 가치 대 원가 또는 시장 중 낮은 가격 측정 문제에서 그렇습니다.

암호 관련 회계 시스템에 대한 BaFin 요구 사항이 있나요?

BaFin은 특정 소프트웨어 플랫폼을 요구하지 않지만, 규제 대상 기업이 전통적인 금융 상품을 보유하는 것과 동일한 수준으로 기록을 유지할 것을 기대합니다. 펀드 및 면허를 받은 암호 수탁자의 경우, 이는 평가 문서, 완전한 거래 내역, 요청 시 기록을 생성할 수 있는 능력을 의미합니다. 이러한 기능을 입증할 수 없는 소프트웨어는 규제 위험을 초래합니다.

Source: CryptaCount