SPED 수동 검토로 인해 브라질 회계사가 연간 80시간 이상을 낭비하는 이유

매년 6월 30일 디지털 회계 장부(ECD) 제출 마감과 7월 31일 디지털 세무 장부(ECF) 제출 마감을 앞둔 몇 주 동안, 브라질 전역의 회계 팀은 같은 패턴을 반복합니다. 공식 검증 프로그램(PVA)에서 ECD 파일을 열고, .txt 사본을 내보낸 후, 파이프 구분 기호를 사용하여 Excel로 가져와 수동 검토를 시작합니다. 목표는 분석이 아닙니다. 확인입니다. 즉, 시스템이 제출하려는 데이터에 세무 감사, 과태료 또는 신고를 지연시키는 막판 수정을 유발할 수 있는 중대한 불일치가 없는지 확인하는 것입니다.

이 글은 SPED를 신고하는 방법에 관한 것이 아닙니다. 중견 기업의 경우 매년 40~80시간이 소요되는 수동 검토 단계가 왜 존재하는지, SPED 형식의 어떤 구조적 특징 때문에 표준 도구로는 이를 피할 수 없는지, 그리고 "그냥 더 일찍 시작하라"는 조언이 왜 완전한 해결책이 아닌지에 대해 설명합니다.

끊임없이 흘러가는 시계: SPED의 연간 카운트다운

일정은 의도적으로 빡빡하게 설계되었습니다. ECD는 전년도 데이터 기준으로 해당 연도 6월 마지막 영업일까지 제출해야 합니다. 예를 들어 2025년 데이터의 경우 2026년 6월 30일까지입니다. ECF는 한 달 뒤인 7월 31일까지 제출해야 합니다. 두 마감일 사이에 회계 팀은 전년도 결산을 마감하고, ECD 파일을 생성 및 검증하여 제출한 후, ECD 출력물을 기반으로 ECF의 세금 계산을 수행해야 합니다. 따라서 ECD 제출 후 ECF 마감일까지 실질적으로 작업 가능한 시간은 약 4~6주 정도이며, 이 기간 동안 팀은 ECD 데이터의 일관성을 확인하고 ECF 조정 항목이 ECD 데이터에서 올바르게 도출되었는지 확인하는 수동 검토도 병행해야 합니다.

두 마감일 중 하나라도 놓칠 경우의 결과는 자동으로 정해져 있습니다. 법률 제10.426/2002호에 따라 ECD 지연 제출 시 월 R$5,000, ECF 지연 제출 시 월 R$500의 벌금이 부과됩니다. 그러나 벌금은 이야기의 일부일 뿐입니다. 제출이 늦거나 데이터가 일관되지 않으면 세무 조사 대상으로 지정될 가능성이 높아집니다. 이 경우 발생하는 비용은 월별 벌금을 훨씬 상회하며, 직접적인 전문가 수수료와 간접적인 경영진의 업무 차질 모두를 포함합니다.

따라서 이러한 압박은 인위적인 것이 아닙니다. 이는 구조적인 문제입니다. 마감일은 여유가 거의 없고, 벌금은 실질적이며, 수동 검토는 파일에 저장된 데이터와 헤세이타 페데랄이 보게 될 데이터 사이의 유일한 안전장치입니다.

"데이터가 정확합니다"를 확인하는 데 40~80시간이 걸리는 이유

SPED 수동 검토에 이렇게 많은 시간이 소요되는 이유를 이해하려면 중견 기업의 ECD 파일에 실제로 무엇이 포함되어 있는지 살펴봐야 합니다. ECD 파일은 공공 디지털 장부 시스템(SPED) 레이아웃 사양에 따라 구조화된 일반 텍스트 문서입니다. 모든 줄은 해당 레코드 유형을 식별하는 Registro 코드로 시작합니다. 일반적인 파일은 80,000줄에서 150,000줄에 달합니다.

수동 검토자의 작업은 모든 줄을 읽는 것이 아닙니다. 주요 Registro 그룹(시산표(C155), 계정과목표(C050), 마감 잔액(C157), 분개 요약(I200/I250))이 내부적으로 일관성이 있는지, 그리고 ECF의 세금 조정 항목이 기본 ECD 데이터와 일치하는지 확인하는 것입니다. 실제로 이는 파일에서 데이터 하위 집합을 추출하고, 합계를 상호 참조하며, 특정 계정 잔액을 한 섹션에서 다른 섹션으로 추적하는 것을 의미합니다.

SPED 형식의 세 가지 구조적 특징으로 인해 이 작업은 예상보다 훨씬 더 많은 시간을 소모하게 됩니다.

구조적 문제 1: Excel이 구조화된 데이터로 읽을 수 없는 고정 너비 텍스트

ECD 파일은 스프레드시트가 아닙니다. 각 Registro 유형이 특정 문자 위치에 자체 필드 레이아웃을 가지며 파이프 문자로 구분되는 고정 너비 텍스트 파일입니다. 파이프 구분 기호로 텍스트 가져오기 마법사를 사용하여 Excel에서 열면 모든 줄이 행이 되지만, 각 열의 의미는 전적으로 첫 번째 열에 나타나는 Registro 코드에 따라 달라집니다.

C155 Registro에는 390자 구조 내 특정 위치에 계정 코드, 기초 잔액, 차변 이동, 대변 이동, 기말 잔액에 대한 필드가 있습니다. I200 Registro에는 분개일, 분개 번호, 총 금액에 대한 필드가 있으며, 완전히 다른 레이아웃입니다. 원시 Excel 가져오기에서는 둘 다 동일한 스프레드시트에 있으며, G열은 C155 행의 경우 "기초 잔액"을 의미하고 I200 행의 경우 "분개 합계"를 의미할 수 있습니다. 스프레드시트는 이들을 다르게 처리할 방법이 없습니다.

시산표만 추출하기 위해 검토자는 A열이 "C155"와 같은 행에 대해 스프레드시트를 필터링합니다. 이렇게 하면 표시되는 데이터가 시산표 레코드로 줄어들지만 열 머리글은 여전히 일반적입니다. 검토자는 C155 행의 H열이 기초 잔액에 해당하고 I열이 차변 이동에 해당한다는 것을 기억하거나 조회해야 합니다. 필터의 단일 오타나 가져오기 중 열 위치가 잘못되면 그럴듯해 보이지만 구조적으로 잘못된 데이터 세트가 생성됩니다. 시간 비용은 필터링만이 아닙니다. 수천 개의 행을 스캔하는 동안 필드 레이아웃을 머릿속에 유지해야 하는 정신적 부담입니다.

구조적 문제 2: 단일 파일에 40개 이상의 Registro 유형

ECD 레이아웃은 6개의 Bloco(0, C, I, J, K, 9)에 걸쳐 40개 이상의 고유한 Registro 유형을 정의합니다. 각 Registro 유형은 필드 레이아웃이 다릅니다. 시산표(C155)를 분개(I200) 및 원가 센터 할당(C100)과 상호 참조해야 하는 검토자는 동일한 파일에서 각각 고유한 열 매핑이 있는 세 가지 다른 하위 집합을 추출한 다음, 이들 간의 합계를 수동으로 조정해야 합니다.

ECF는 또 다른 복잡성을 추가합니다. 해당 Registro 구조에는 Bloco E, Bloco M(e-Lalur 및 e-Lacs 조정), Bloco Y(특수관계자 및 이전 가격 정보)가 포함됩니다. ECF의 M300 Registro는 ECD의 C050 계정과목표의 특정 계정 코드를 참조합니다. 이는 검토자가 두 개의 독립적인 .txt 파일을 열고, 각각에서 일치하는 하위 집합을 추출하고, 수동으로 일관성을 확인해야 하는 파일 간 종속성입니다.

PVA에서 수행하는 검증은 이 파일 간 일관성을 확인하지 않습니다. PVA는 각 개별 파일이 레이아웃 사양을 충족하는지 확인합니다. ECD의 계정 4.01.01에 대한 기말 잔액이 ECF의 E010 복구 레코드로 가져온 기초 잔액과 일치하는지 확인하지 않습니다. 그 확인은 전적으로 인간 검토자에게 맡겨집니다.

구조적 문제 3: PVA에 내장된 파일 간 교차 검증 부재

이는 SPED 생태계에서 가장 중요한 결함입니다. ECD 및 ECF용 Programas Validadores e Assinadores(PVA)는 독립적으로 작동합니다. 각 파일 내에서 구문, 필드 범위 및 Registro 순서를 검증합니다. 그러나 두 파일 간의 데이터를 상호 참조하지는 않습니다. ECD의 특정 계정 마감 잔액이 ECF가 Bloco E에서 복구한 기초 잔액과 다른 불일치를 식별하지 않습니다. ECF의 M300 조정이 ECD의 회계 설정과 일치하는지도 확인하지 않습니다.

물론 헤세이타 페데랄(RFB)은 제출 후 이러한 교차 검증을 수행합니다. RFB 자체 시스템은 2026년부터 인공지능 기능이 강화된 점점 더 정교한 자동화된 교차 점검을 사용하여 ECD 데이터를 ECF 데이터와, ECF를 DCTF와, ECD를 EFD-Contribuições와 비교합니다. 제출 후 불일치가 발견되면 회사는 통지를 받고, 조정이 기록되며, 세무 감사 위험이 증가합니다. 수동 검토만이 이러한 불일치가 영구 기록의 일부가 되기 전에 발견하고 수정할 수 있는 유일한 기회입니다.

결과: 회계사가 자동화된 교차 참조 엔진이 몇 초 만에 수행할 수 있는 작업에 수시간을 소비하게 됩니다. 그리고 RFB는 이미 제출 경계의 반대편에서 그 엔진을 보유하고 있습니다.

연쇄 효과: ECD 검토 지연이 ECF 제출에 미치는 영향

ECF는 회계 기준을 ECD에 의존하기 때문에, ECD 검토의 지연이나 오류는 ECF 일정에 직접적인 영향을 미칩니다. ECF 준비 중에 "이 M300 조정이 해당 ECD 계정과 일치하지 않습니다"와 같은 수정 사항이 발견되면, ECD 파일을 다시 열고, 수정하고, 대체 ECD 파일을 생성하고, PVA에서 재검증한 후 ECF를 진행하기 전에 재제출해야 합니다. 이러한 연쇄적인 재작업은 SPED 주기에서 막바지 스트레스의 가장 큰 원인입니다.

실제로 7월 둘째 주에 ECD↔ECF 불일치를 발견한 회사는 ECF를 최종 확정하기 전에 ECD 수정을 처리해야 하며, 두 파일 모두 7월 31일까지 제출해야 하는 촉박한 일정에 직면합니다. 작업 가능 기간은 몇 주에서 며칠로 줄어들고, 모든 수정은 파일의 다른 곳에서 새로운 불일치를 초래할 위험을 수반합니다.

업계의 방향성

헤세이타 페데랄은 파일 간 분석 기능에 투자하고 있습니다. 2026년 AI 기반 데이터 교차 검증 도입은 제출 측 도구가 할 수 있는 것과 헤세이타 페데랄의 제출 후 분석이 할 수 있는 것 사이의 격차가 벌어지고 있음을 시사합니다. 그러나 납세자 측에서는 제출 전 검토에 사용할 수 있는 도구가 발전 속도를 따라가지 못하고 있습니다. PVA는 형식을 검증합니다. Excel은 Registro 코드로 필터링합니다. 그 사이의 모든 것, 즉 데이터가 일관되고 완전하며 한 파일에서 다음 파일로 일치하는지 실제로 확인하는 작업은 여전히 수동으로 이루어집니다.

이러한 비대칭성이 회계사들이 SPED 검토에 수 주를 소비하는 근본적인 이유입니다. 느리거나 준비가 부족해서가 아니라, 형식이 회사의 가장 중요한 재무 데이터를 서로 다른 구조를 가진 여러 텍스트 파일에 분산시키고, 사용 가능한 도구는 독자가 수만 줄을 스캔하는 동안 필드 레이아웃과 파일 간 관계를 머릿속에 유지해야 하기 때문입니다. 외부에서는 준비 문제처럼 보이지만 실제로는 형식 문제이며, 해결책이 동기 부여가 아닌 구조적이기 때문에 이 차이는 중요합니다.

핵심 인사이트: SPED 수동 검토 문제는 "마감까지 시간이 너무 부족한" 문제가 아닙니다. 너무 많은 Registro 유형, 너무 적은 파일 간 참조, 그리고 PVA의 형식 검증과 사람 검토자의 눈 사이에 분석 도구가 전혀 없는 문제입니다. 바이트 오프셋이 아닌 의미별로 여러 Registro 유형을 읽고 동일한 세션에서 모든 SPED 파일로부터 구조화된 테이블을 생성할 수 있는 도구는 편의성이 아닙니다. 이는 구조적 문제에 대한 구조적 해결책입니다.

자주 묻는 질문

Q: 중견 기업의 경우 전체 ECD 수동 검토에 일반적으로 얼마나 걸립니까?

보고된 회계 법인 워크플로우에 따르면, ECD 데이터가 80,000~150,000줄인 기업의 완전한 ECD↔ECF 교차 참조 검토는 연간 8~12시간이 소요됩니다. 3년 비교 기간의 경우 교차 참조 단계만 총 30시간이 넘으며, 초기 데이터 추출 및 서식 작업 시간은 포함되지 않습니다.

Q: PVA가 데이터 불일치를 감지합니까?

PVA는 구문과 형식 준수 여부를 검증합니다. 서로 다른 Registro 유형 간 또는 ECD와 ECF 파일 간의 의미론적 교차 검증은 수행하지 않습니다. 전년도 기말 잔액과 일치하지 않는 기초 잔액이 있는 C155 레코드는 필드 형식이 올바르면 PVA 검증을 통과합니다.

Q: 수동 검토 중 발견되는 가장 일반적인 불일치는 무엇입니까?

가장 빈번한 문제는 ECD의 기말 잔액과 Bloco E(E010)의 ECF 복구 잔액 간 불일치, 기초 충당금 대비 M300 조정 금액 오류, E015 매핑 계정 테이블의 교차 참조 누락입니다. 이는 모두 PVA가 포착하지 못하는 파일 간 불일치입니다.

Q: 회사에서 SPED 모듈이 포함된 주요 ERP를 사용하는 경우에도 수동 검토가 필요한가요?

네, 필요합니다. ERP 모듈(SAP TDF, Oracle NetSuite Brazil Localization, Senior, Domínio)은 회사의 거래 데이터를 기반으로 ECD 및 ECF 파일을 생성합니다. 하지만 생성된 ECD와 ECF 출력물 간의 교차 파일 일관성 검사를 수행하지는 않습니다. 파일 생성은 자동화되어 있지만, 데이터 검증은 그렇지 않습니다. 수동 검토 단계는 생성 도구의 기능이 아니라 SPED 형식 자체의 기능입니다.

Q: ECF 제출 후 불일치가 발견되면 어떻게 되나요?

회사는 수정된 데이터로 대체 ECF(ECF retificadora)를 제출합니다. 헤세이타 페데랄은 위험 점수 산정 과정의 일부로 원본 제출분과 수정 제출분을 비교합니다. 빈번한 수정이나 큰 금액 변동을 수반하는 수정은 회사의 감사 위험 점수를 높입니다. RFB의 상호 참조 엔진은 제출된 ECD, ECF, DCTF 및 EFD-Contribuições 데이터 간의 불일치를 자동으로 식별합니다.

Q: AI 추출 도구가 SPED 수동 검토 시간을 줄이는 데 도움이 될 수 있나요?

맞춤 열 추출을 사용하는 ImageToTable.ai와 같은 도구는 검토의 데이터 준비 부분을 몇 시간에서 몇 분으로 단축할 수 있습니다. 검토자는 여전히 전문적인 판단을 적용하지만, 혼합된 Registro 유형이 있는 원시 파이프 구분 텍스트가 아닌 깔끔한 데이터를 대상으로 합니다. 시간 절약은 현재 검토 주기의 대부분을 소비하는 필터링, 열 재매핑 및 구조적 정리 단계를 제거함으로써 이루어집니다.

마감일을 넘어 — 더 나은 도구가 필요한 프로세스

매년 반복되는 SPED 검토 주기에는 근본적인 불일치가 있습니다. 데이터가 저장된 형식과 이를 검증하는 데 사용하는 도구는 서로 다른 목적으로 설계되었습니다. SPED 형식은 기계 검증을 위해 설계되었습니다 — 고정 너비 필드, Registro 코드, 파이프 구분 기호, 모두 파서에 최적화되어 있습니다. 대부분의 회계사가 검토에 사용하는 도구는 범용 스프레드시트로, Registro 유형에 관계없이 모든 행을 동일하게 처리합니다. 검토자는 이 둘 사이의 간극을 메워야 하며, 이 연결 작업이 매년 40~80시간을 소요하게 만듭니다.

기술적인 의미에서 이 간극을 메우는 것은 어렵지 않습니다. 기계적으로 반복적일 뿐입니다: 필터링, 확인, 매핑, 검증, 다른 Registro 코드로 다시 필터링, 반복. 추출 단계가 Registro 유형을 필터가 아닌 의미로 이해하게 되면 이 작업은 사라집니다. 6월~7월 마감 주기에 직면한 브라질 회계 팀에게 질문은 수동 검토가 필요한지 여부가 아니라, 그에 앞서 데이터 준비가 가용 시간의 대부분을 차지해야 하는지입니다.