SPED 수동 검토가 브라질 회계사에게
생각보다 더 많은 시간을 소요하게 하는 이유

이 글은 SPED를 제출하는 방법에 관한 것이 아닙니다. 중견기업이 매년 40~80시간을 소요하는 수동 검토 단계가 왜 존재하는지, SPED 형식의 어떤 구조적 특성 때문에 표준 도구로는 이를 피할 수 없는지, 그리고 "그냥 일찍 시작하면 된다"는 답변이 왜 완전하지 않은지에 관한 글입니다.

멈추지 않는 시계: SPED의 연간 카운트다운

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

두 마감일 중 하나라도 지키지 못하면 자동으로 벌금이 부과됩니다. ECD 지연 제출 시 월 R$5,000, ECF 지연 제출 시 법률 제10.426/2002호에 따라 월 R$500(최소 R$1,500)입니다. 그러나 벌금은 이야기의 일부에 불과합니다. 지연되거나 불일치하는 제출은 세무 조사 대상으로 지정될 가능성을 높이며, 그 비용은 직접적인 전문가 수수료와 간접적인 경영진의 업무 분산 모두에서 월 벌금을 훨씬 초과합니다.

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

"데이터가 정확하다"는 것을 확인하는 데 40~80시간이 걸리는 이유

수동 SPED 검토가 왜 이렇게 많은 시간을 소요하는지 이해하려면 중견 기업의 ECD 파일에 실제로 무엇이 포함되어 있는지 살펴봐야 합니다. 이 파일은 공공 디지털 회계 시스템(Sistema Público de Escrituração Digital, SPED) 레이아웃 사양 — 현재 ECD는 Leiaute 9, ECF는 Leiaute 12 — 에 따라 구조화된 일반 텍스트 문서입니다. 모든 줄은 해당 레코드 유형을 식별하는 Registro 코드로 시작합니다. 일반적인 파일은 80,000~150,000줄에 달합니다.

수동 검토자의 작업은 모든 줄을 읽는 것이 아닙니다. 핵심 Registro 그룹 — 시산표(C155), 계정과목표(C050), 기말잔액(C157), 분개 요약(I200/I250) — 이 내부적으로 일관성이 있는지, 그리고 ECF의 세무 조정(M300 for e-Lalur, M350 for e-Lacs)이 기반 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(복구된 ECD 데이터), Bloco M(e-Lalur 및 e-Lacs 조정), Bloco Y(특수관계자 및 이전가격 정보)가 포함됩니다. ECF의 M300 Registro(e-Lalur Part A 조정)는 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 자체 시스템은 2026년부터 인공지능 기능으로 강화된 점점 더 정교한 자동 교차 검증을 사용하여 ECD 데이터를 ECF 데이터와, ECF를 DCTF와, ECD를 EFD-Contribuições와 비교합니다. 제출 후 불일치가 발견되면 회사는 통지를 받고, 조정이 기록되며, 감사 위험이 증가합니다. 수동 검토는 이러한 불일치가 영구 기록의 일부가 되기 전에 발견하고 수정할 수 있는 유일한 기회입니다.

결과: 회계사가 자동화된 상호 참조 엔진이 몇 초 만에 수행할 수 있는 작업에 몇 시간을 소비하는 프로세스가 됩니다. 그리고 RFB는 이미 제출 경계선 너머에 그 엔진을 보유하고 있습니다.

연쇄 효과: ECD 검토 지연이 ECF 제출을 지연시키는 경우

ECF는 회계 기준을 ECD에 의존하므로(Bloco E는 ECD의 최종 잔액과 매핑된 계정을 복구함), ECD 검토의 지연이나 오류는 ECF 일정에 직접 전파됩니다. ECF 준비 중 발견된 수정 사항 — "이 M300 조정이 해당 ECD 계정과 일치하지 않습니다" — 은 ECD 파일을 다시 열고, 수정하고, 대체 ECD 파일을 생성하고, PVA에서 재검증한 후 ECF를 진행하기 전에 다시 제출해야 합니다. 이러한 연쇄 재작업은 SPED 주기에서 막판 스트레스의 가장 큰 원인입니다.

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

업계의 방향 (그리고 수동 검토가 지속되는 이유)

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

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

자주 묻는 질문

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

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

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