GST/HST 신고 데이터 입력 비용, CRA 양식보다
캐나다 중소기업에 더 큰 부담

GST34-2는 네 가지 질문을 묻지만, 답을 찾는 데 나머지 세 시간이 소모됩니다

CRA의 My Business Account에서 "제출"을 클릭하는 데는 약 90초가 걸립니다. 이것이 모든 사람이 볼 수 있는 신고의 일부이며, 진정으로 빠른 부분입니다. 실제 작업은 달력에 표시되지 않는 곳에서 이루어집니다. 분기별 신고자의 경우 각 신고 기간 다음 달 30일인 마감일 전날 저녁이나 주말에 공급업체 PDF를 하나씩 열고, 각각의 세금 항목을 찾고, 해당 공급업체 주에 맞는 세율인지 확인한 후, 그 어떤 PDF도 읽을 수 없는 스프레드시트에 숫자를 입력하는 작업입니다.

캐나다의 약 350만 GST/HST 등록 사업자에게 신고 문제는 결코 양식 자체가 아니었습니다. 문제는 양식을 작성하기 전에 반드시 충족되어야 하는 모든 것, 그리고 이 두 가지 사이의 간극에 데이터 입력 비용이 존재한다는 점입니다.

마지막 공급업체 PDF에서 106번 항목까지 실제로 일어나는 일

일반적인 소기업(폴더에 공급업체 구매 송장 40개가 있는 밴쿠버 기반 리모델링 업체)의 분기별 데이터 조립 과정을 살펴보면 문제의 형태가 드러납니다.

세 단계를 합치면 분기당 약 2~3시간이 소요되며, 이는 일반적인 공급업체를 보유한 소규모 기업 기준입니다. 연간 4분기로 계산하면 8~12시간의 작업이 수익, 인사이트, 전략적 가치를 전혀 창출하지 못합니다. 이는 순수하게 데이터를 한 형식에서 다른 형식으로 옮기는 작업일 뿐입니다. 게다가 이 전송은 취약합니다. 1분기와 3분기 사이에 청구서 레이아웃을 변경하는 단 한 곳의 공급업체나, QST 항목을 GST로 잘못 인식한 퀘벡 공급업체 하나만 있어도 106행의 숫자가 틀어질 수 있으며, 그 오차는 CRA(캐나다 국세청)의 검토를 촉발할 만큼 충분히 큽니다.

회계 소프트웨어가 공급업체의 PDF를 읽지 못하는 이유와 수동 작업이 살아남는 이유

캐나다 소규모 기업 회계 시장은 잘 갖춰져 있습니다. QuickBooks Online Canada, Xero, Sage 50, Wave는 모두 GST/HST 코딩을 처리하고, 순 세금 계산을 자동화하며, CRA의 NETFILE 서비스를 통해 직접 신고서를 제출할 수도 있습니다. 겉으로 보기에는 문제가 해결된 것처럼 보입니다. 회계 소프트웨어가 세율을 알고, 거래를 GST34-2의 올바른 항목에 매핑하며, 신고서를 제출합니다. 하지만 이 소프트웨어가 할 수 없는 것, 그리고 시중의 어떤 회계 소프트웨어도 할 수 없는 것은 공급업체의 PDF를 읽어 청구서에서 GST/HST 금액을 찾아내는 일입니다.

이것이 수동 단계를 살아있게 만드는 구조적 격차입니다. 공급업체가 PDF 청구서를 이메일로 보냅니다. 은행 피드가 거래와 일치하면 회계 소프트웨어는 지불을 기록할 수 있습니다. 하지만 해당 청구서의 세금 금액, 즉 사업체가 청구할 수 있는 ITC(매입세액공제) 금액을 결정하는 숫자는 사람이 읽고 소프트웨어에 입력하기 전까지는 PDF에만 존재하는 데이터입니다. 모든 SaaS 구독 청구서, 모든 도매 공급업체 명세서, 모든 철물점 영수증 — 이 각 문서의 세금 항목은 이를 필요로 하는 회계 시스템에 보이지 않습니다.

이 격차는 QuickBooks의 문제나 Xero의 문제가 아닙니다. 이는 문서 형식의 문제입니다. PDF는 기계 추출이 아닌 사람이 읽도록 설계된 시각적 매체입니다. 회계 소프트웨어는 숫자가 시스템에 입력되면 GST/HST를 계산할 수 있습니다. 이 숫자들을 시스템에 넣는 것이 소프트웨어 자체적인 연결 다리가 없는 단계이며, 그 다리는 바로 PDF를 열고 입력하는 사람입니다.

5개 주, 5가지 세율 — 캐나다 GST/HST 시스템이 수동 ITC 계산을 특히 오류에 취약하게 만드는 이유

대부분의 부가가치세(VAT) 국가는 단일 전국 세율을 적용합니다. 하지만 캐나다는 그렇지 않습니다. 바로 이 점 때문에 수동 ITC 계산이 호주의 수동 BAS 제출이나 영국의 수동 VAT 신고 준비와는 질적으로 다른 문제가 됩니다. 5개 주에 공급업체를 둔 캐나다 소기업은 5가지 다른 연방 세율이 적용된 문서를 처리해야 하며, 각 인보이스의 세율은 공급업체 소재지를 기준으로 확인되어야 합니다. 추정하거나 유추하는 것이 아니라, 반드시 확인해야 합니다.

온타리오, BC, 퀘벡, 노바스코샤에 공급업체가 있는 기업(전국적으로 자재를 구매하는 회사에게 흔한 조합)은 단일 분기 동안 4가지 다른 연방 세율이 적용된 인보이스를 처리합니다. 확인 단계는 한 번의 점검이 아닙니다. 각 주의 인보이스 하위 집합에 각각 적용되는 4번의 개별 점검입니다. 그리고 1분기에 온타리오 창고에서 배송하여 13% HST를 청구했던 동일한 공급업체가 3분기에는 BC 창고에서 배송하여 5% GST를 청구할 수도 있습니다. 세율은 공급업체 본사 소재지가 아닌 공급 지점을 따릅니다. 숫자를 입력하는 사람은 이 변화를 포착해야 합니다. 한 번에 30개의 인보이스를 처리하다 보면, 이를 놓칠 확률이 포착할 확률에 근접합니다.

분기별 일괄 처리 워크플로는 수식 기반 확인(=IF(AND(H2="BC", G2<>5%), "VERIFY", ""))을 도입하여 세율-주 불일치를 자동으로 표시합니다. 하지만 이 워크플로는 데이터가 이미 스프레드시트에 있다고 가정합니다. 지금 읽고 계신 이 글은 스프레드시트가 존재하기 전 단계, 즉 40개의 PDF에서 데이터가 열(column)로 이동하고, 유일한 확인 수단은 체인에서 가장 비싸고 가장 신뢰할 수 없는 구성 요소인 사람의 눈 한 쌍뿐인 단계에 관한 것입니다.

문제 해결 방법은 더 빠른 입력이 아닙니다 — 입력 자체를 없애는 것입니다

단일 분기 GST/HST 추출 가이드에 설명된 GST/HST 추출 워크플로우는 정확히 이 문제를 해결합니다. 신고 단계가 아닌 입력 단계를 변경함으로써 해결합니다. 공급업체명, 송장 날짜, 송장 합계, 납부한 GST/HST, 적용된 세율, 공급업체 주(Province) 등 여섯 개의 열을 정의하고, 40개 공급업체의 PDF를 한 번에 업로드하면 AI가 필드 위치가 아닌 필드 의미를 기준으로 각 문서를 읽습니다. 출력 결과는 모든 세금 수치가 해당 열에 이미 입력되어 있고, 모든 주(Province)가 이미 채워져 있으며, 모든 세율이 육안 검증이 아닌 수식으로 검증될 준비가 된 스프레드시트입니다.

메커니즘의 차이가 핵심입니다. 기존 OCR 도구는 각 공급업체 송장에서 세금 항목이 어디에 있는지 알아야 합니다. 위치를 기준으로 읽기 때문에, 공급업체가 템플릿을 재설계하여 HST 항목을 바닥글에서 2페이지로 옮기면 추출이 실패합니다. AI 의미론적 추출은 의미를 기준으로 읽습니다. 송장에서 GST/HST 금액을 나타내는 필드가 어디에 위치하든 찾아냅니다. Home Depot PDF, BC주 배관공의 손글씨 영수증, TPS와 TVQ 항목이 분리된 퀘벡주 목재 공급업체의 송장 모두 동일한 열에 입력됩니다. AI는 퀘벡 송장에서 "TPS 5%"를 읽고 TPS 금액을 납부한 GST/HST 열로 추출합니다. 열 이름이 "납부한 GST/HST"이므로 연방 구성 요소만 추출하라는 지시에 따라 TVQ 항목은 무시합니다.

변경되는 것은 신고 워크플로우, 회계 소프트웨어 또는 CRA와의 관계가 아닙니다. 변경되는 것은 세 시간이 걸리던 데이터 수집 단계(세금 항목 찾기, 주별 세율 확인, 숫자 입력)가 몇 분의 업로드와 출력 결과 검토로 단축된다는 점입니다. QuickBooks나 Xero는 여전히 신고를 처리합니다. 회계사는 여전히 신고서를 검토합니다. 사라지는 유일한 것은 40개의 PDF를 하나씩 열고, 회계 소프트웨어가 숫자만 있으면 완벽하게 계산할 수 있는 숫자를 직접 입력하는 부분입니다.

동일한 구조적 문제가 다른 세무 관할권에서도 규제 방식만 다를 뿐 존재합니다. 호주 BAS 제출 문제도 같은 패턴을 보입니다 — 혼합 형식의 공급업체 문서를 기반으로 한 분기별 GST 정산이며, 단일 국가 GST율(10%)이라는 단순함과 면세/과세 공급 분류라는 복잡함이 공존합니다. 호주 PAYG 요약 문제도 동일한 데이터 수집 공백을 급여 신고에 적용한 사례입니다: STP가 대부분의 수동 입력을 없앴지만, 정산 시간의 80%를 소모하는 예외 사례들이 여전히 남아 있습니다. 모든 경우에서 해결책은 더 빠른 입력 프로세스나 더 잘 정리된 PDF 폴더가 아닙니다. 해결책은 PDF가 스프레드시트와 만나는 지점에서 입력 단계 자체를 제거하는 것입니다 — 그 단계야말로 기계가 사람보다 더 정확하게 수행할 수 있는 유일한 단계이기 때문입니다.

FAQ: 수동 GST/HST 신고 데이터 입력

분기별 GST/HST 신고서는 복잡한 양식이 아닙니다. 복잡한 데이터를 입력받는 간단한 양식입니다. 즉, PDF 40개, 주별 세율 5개, 그리고 이 중 어느 것도 읽을 수 없는 스프레드시트로 구성되어 있습니다. 분기당 데이터 수집에 소요되는 3시간은 최적화해야 할 생산성 문제가 아닙니다. 이는 제거해야 할 형식 변환 문제이며, 공급업체 PDF가 사람의 개입 없이 스프레드시트 열로 이동하는 순간 제거됩니다.