4분기
AU BAS를 연간 세무 원장으로 일괄 처리하는 방법

분기별 BAS 마감 뒤에 숨은 규모의 문제

Simpler BAS 방식을 사용하여 단일 고객을 위해 준비된 단일 분기별 BAS에는 3개의 GST 레이블(G1, 1A, 1B)이 포함되며, 사업체에 직원이 있는 경우 PAYG 원천징수 필드(W1, W2)가 두 개 더 포함될 수 있습니다. 해당 레이블 뒤에 있는 문서(공급업체 송장 15~25개, 조정을 위한 은행 거래 명세서, 급여 요약)를 취합하고 확인하는 데 30~45분이 소요됩니다. 그 시간은 합리적으로 느껴집니다. 대부분의 부기 담당자가 워크플로에 의문을 제기하지 않는 이유입니다. 고객당 분기당 45분은 연간 고객당 3시간에 해당하며, 청구 가능 요금 $100~$150/시간 기준으로 연간 $300~$450에 달합니다. 관리 가능한 수준입니다.

규모가 커지면 계산이 달라집니다. 분기별로 신고하는 고객이 30명인 BAS 에이전트는 연간 120개의 BAS 기간을 처리합니다. 각각 45분씩이라면 문서를 스프레드시트로 옮기는 작업에 90시간, 즉 PDF에서 숫자를 원장 행으로 옮기는 데 2주의 전체 근무 시간이 소요됩니다. 그리고 이것은 모든 공급업체 송장이 GST 금액이 명확하게 표시된 일관된 형식으로 도착하고, 모든 은행 거래 명세서가 첫 번째 시도에서 조정되며, 신고가 밀려 과거 BAS 기간을 재구성해야 하는 고객이 없다는 최상의 시나리오입니다.

대부분의 부기 업체의 현실은 ASBFEO 조사 결과에 더 가깝습니다. 중소기업의 39%가 규제 준수에 주당 6시간 이상을 소비하며, BAS 신고는 그 부담의 중심에 있습니다. 세 분기가 연체된 신규 고객이 발생하면 부기 담당자는 하나의 BAS를 처리하는 것이 아니라 9개월에 걸친 혼합 형식의 원본 문서를 바탕으로 처음부터 네 개의 BAS를 처리해야 합니다. 시간은 배가되지만 열은 변하지 않습니다. ATO 레이블은 7월이나 4월이나 동일합니다. 변하는 것은 출력 구조가 아니라 입력 문서의 양입니다.

단일 분기 추출 접근 방식(자세한 내용은 단계별 AU BAS 추출 가이드에서 확인 가능)은 자체 분기별 BAS를 처리하는 사업주에게 완벽하게 작동합니다. 연간 120개의 BAS 기간을 운영하는 부기 담당자의 경우 병목 현상은 분기당 추출 로직이 아닙니다. 문제는 동일한 추출 로직을 여러 고객의 다양한 문서 세트에 적용해야 하고, 네 분기의 결과를 각 고객에 대한 하나의 일관된 연간 원장으로 통합해야 한다는 사실입니다. Q1, Q2, Q3, Q4를 회계사가 EOFY에 ATO에 제출할 수 있는 단일 세금 원장으로 병합하는 이 통합 단계에서 대부분의 워크플로가 무너집니다.

일괄 BAS 처리가 부기 담당자에게 실제로 의미하는 바

이 맥락에서 일괄 처리는 한 번에 하나씩 업로드하는 대신 50개 파일을 한꺼번에 업로드하는 것만을 의미하지는 않습니다. 물론 그것도 일부이긴 하지만요. BAS 부기에서의 일괄 처리 과제는 매트릭스 관리입니다. N명의 고객이 있고, 각 고객은 M개의 분기별 BAS 기간을 가지며, 각 기간은 K개의 출처 문서 유형(공급업체 인보이스, 판매 인보이스, 은행 명세서, 급여 요약)에서 데이터를 가져옵니다. 30명의 고객을 담당하는 부기 담당자는 30 × 4 × 4 = 480개의 문서 유형 매트릭스를 관리하는 셈입니다. 이 매트릭스의 출력 측면은 고객별, 분기별로 구조화된 숫자 집합이며, 이 모든 숫자는 궁극적으로 연간 세금 원장으로 통합되어야 합니다.

이 매트릭스를 어렵게 만드는 것은 문서의 양이 아니라 셀 간의 일관성 요구사항입니다. 1분기 카페 고객의 G11 수치(비자본 지출, GST 포함)는 2분기, 3분기, 4분기의 동일 수치와 비교 가능해야 합니다. 부기 담당자가 3월에는 지출을 자본(G10)으로 분류했지만 6월에는 동일 공급업체에 대해 비자본(G11)으로 분류했다면(3월 인보이스는 스크린샷에서 수동 입력했고 6월 인보이스는 Xero에서 코딩했기 때문에), 연간 원장에는 회계사가 EOFY 조정 시 지적할 분류 불일치가 발생합니다. GST 구성 요소가 어느 쪽이든 11로 나누어졌기 때문에 BAS 자체는 매 분기 올바르게 신고되었습니다. 그러나 연간 세금 계획의 작업 문서인 원장은 오염됩니다.

바로 여기서 맞춤 열 추출이 구조적 해결책이 됩니다. 이는 AI가 각 필드가 무엇을 의미하는지(어디에 위치하는지가 아니라) 이해하여 모든 문서에서 일치하는 데이터를 찾는 데 사용하는 열 이름 집합을 정의하는 것입니다. 부기 담당자가 공급업체명, 인보이스 합계(GST 포함), GST 금액, 구매 유형(자본/비자본)과 같은 열을 고객당 한 번 정의하면, 모든 분기의 모든 문서가 동일한 의미론적 추출 로직을 통해 처리됩니다. 1분기의 Bunnings 인보이스와 3분기의 Bunnings 인보이스는 동일한 열에 동일한 분류 규칙으로 결과를 생성합니다. 일관성은 열 정의에 내장되며, 부기 담당자가 3개월 전에 유사한 거래를 어떻게 코딩했는지 기억하는 데 의존하지 않습니다.

회계 소프트웨어가 해결하지 못하는 문서-원장 간극

Xero, MYOB, QuickBooks Online — 호주 대부분의 부기 업무가 기반을 둔 이 세 플랫폼은 거래 데이터가 시스템에 입력된 후에는 BAS 준비를 잘 처리합니다. Xero의 BAS 모듈은 분류된 거래에서 GST 합계를 가져와 SBR을 통해 ATO에 직접 제출할 수 있습니다. MYOB의 BASlink는 AccountRight 생태계 내에서 동일한 기능을 수행합니다. QuickBooks Online의 GST 센터는 분기 내내 미지급 부채를 추적합니다. 문제는 제출 워크플로우가 아니라, 거래가 원장에 존재하기 전에 발생하는 단계에 있습니다.

공급업체가 PDF 인보이스를 이메일로 보내면, 누군가가 이를 읽어야 합니다. Xero의 Hubdoc은 템플릿 기반 OCR을 사용하여 일부 인보이스에서 데이터를 캡처할 수 있지만, 인식하지 못하는 형식의 공급업체에 대해서는 수동 확인이 필요합니다. 여러 산업의 고객을 관리하는 부기 담당자에게 이는 대부분의 공급업체에 해당합니다. MYOB의 동등한 기능(MYOB Capture)은 영수증 캡처를 제공하지만 라인 항목을 추출하지는 않습니다. QuickBooks의 영수증 캡처는 기본 합계를 처리하지만 GST 처리 및 구매 유형 분류를 위해 여전히 수동 코딩이 필요합니다. 이러한 도구 중 어느 것도 스캔된 BAS 양식이나 거래처 직원의 손글씨 영수증을 읽고 G-라벨을 직접 입력할 수 없습니다.

그 결과 대부분의 부기 담당자는 병렬 스프레드시트 워크플로우를 운영합니다. PDF를 폴더로 내보내고, 열고, 공급업체 이름, 인보이스 합계, GST 금액을 Excel에 입력한 다음, 해당 Excel을 회계 소프트웨어로 가져오거나 수동으로 청구서를 작성할 때 참조 자료로 사용합니다. 분기당 한 명의 고객에게는 이 스프레드시트 단계가 번거로움에 불과합니다. 30명의 고객에게는 풀타임 직업입니다. 존재하는 부기 업무 관리 도구(Keeper, Financial Cents, AccountKit)는 작업 완료 및 고객 커뮤니케이션을 추적하지만, 근본적인 문서-데이터 단계를 제거하지는 않습니다. BAS를 제출해야 한다는 것을 알려줄 뿐, 그 안에 들어갈 숫자를 추출하지는 않습니다.

이 간극이 바로 일괄 문서 추출을 BAS 에이전트 워크플로우의 구조적 업그레이드로 만드는 이유입니다. 추출 계층이 PDF 받은 편지함과 회계 소프트웨어 사이에 위치하면, 스프레드시트 단계가 자동화됩니다. 동일한 열 정의, 동일한 출력 구조, 매 분기, 모든 고객에 대해 적용됩니다. 회계 소프트웨어는 여전히 제출 및 은행 거래 조정을 처리하지만, 입력된 데이터가 아닌 추출된 데이터를 수신합니다.

1단계: 클라이언트당 한 번 추출 스키마를 정의하고 모든 분기에 재사용하세요

일괄 BAS 처리의 첫 번째 규칙: 열 정의가 곧 워크플로입니다. 분기마다 열을 다르게 정의하거나, 각 문서를 보면서 즉석에서 정의하면 4분기의 스프레드시트가 각각 다른 구조를 가지게 되며, 이를 연간 원장으로 병합하는 것은 수동 재구성 작업이 됩니다. 클라이언트당 한 번 스키마를 정의하고 고정하세요.

Simpler BAS를 사용하는 일반적인 소규모 비즈니스 클라이언트의 경우 추출 스키마는 간결합니다:

전체 BAS 클라이언트(연매출 ≥1천만 달러)의 경우 수출 매출(G2 입력), GST 면세 매출(G3), 그리고 급여 요약을 추출하는 경우 PAYG 필드(W1, W2)에 대한 열을 추가하세요. 핵심 설계 원칙: 모든 열은 BAS 레이블에 매핑되며, 클라이언트의 BAS에 표시되는 모든 레이블에는 해당 열이 있습니다. 열이 없으면 해당 레이블의 데이터가 원장에서 누락되며, 조정 전까지 이를 알 수 없습니다.

스키마는 재사용 가능한 구성으로 저장됩니다. ATO 레이블이 변경되지 않기 때문에 열 이름과 데이터 유형은 분기 간에 변경되지 않습니다. 1분기와 2분기 사이에 변경되는 것은 추출 로직이 아니라 원본 문서 세트입니다. 카페 클라이언트의 스키마(공급업체, 송장 합계, GST 금액, 매입 유형)는 10월, 2월, 4월, 7월에 동일하게 적용됩니다. 추출 도구는 각 문서를 읽고 각 열 정의와 일치하는 값을 찾아 동일한 구조화된 테이블로 출력합니다. 10월~12월 분기의 공급업체 송장 40개는 1월~3월 분기의 송장 35개와 동일한 열로 40개의 행을 생성합니다. 구조는 훈련이 아닌 설계에 의해 일관성을 유지합니다.

2단계: 고객 및 분기별로 문서 일괄 처리

스키마가 정의되면 처리는 데이터 정리 작업이 됩니다. 처리 전 부기 담당자의 문서 관리 방식에 따라 일괄 실행 결과가 깔끔한 분기별 출력물이 될지, 병합에 골치를 썩일지가 결정됩니다.

추출 계획과 동일한 폴더 구조로 원본 문서를 정리하세요:

이것이 바로 일괄 처리가 단일 문서 추출과 다른 점입니다. 단일 문서 워크플로에서는 파일 하나를 업로드하고, 결과를 기다리고, 확인하고, 다음 파일로 넘어갑니다. 업로드 → 추출 → 확인 → 다음으로 이어지는 이 순차적 루프는 문서당 약 60초가 소요됩니다. 평균 20개의 문서가 있는 120개의 분기 기간의 경우, 문서당 1분씩 총 2,400개 문서는 40시간의 화면 시간이 필요합니다. 일괄 처리는 문서당 대기 시간을 없앱니다. 20개의 문서를 함께 업로드하고 병렬로 처리하며, 출력은 단일 구조화된 테이블로 제공됩니다. 확인 단계는 여전히 필요합니다. 개별 행을 원본 문서와 대조하여 점검해야 하지만, 추출 자체는 확인과 분리되어 있으며 20개의 문서가 하나의 문서와 거의 같은 시간에 완료됩니다.

각 일괄 실행의 출력은 하나의 스프레드시트이며, 각 행은 하나의 원본 문서를 나타내고 각 열은 BAS 라벨에 매핑됩니다. 카페 고객의 Q1 출력은 공급업체명, 송장 합계, GST 금액, 구매 유형 열로 구성된 테이블입니다. Q2 출력도 동일한 구조입니다. Q3와 Q4도 마찬가지입니다. 고객당 4개의 동일한 구조의 스프레드시트가 생성되며, 이는 이후 병합 단계의 전제 조건입니다.

3단계: 분기별 스프레드시트 4개를 하나의 연간 세금 원장으로 병합

병합 단계는 분기별 일괄 출력이 연간 작업 문서로 전환되는 단계입니다. 각 분기 스프레드시트의 열 구조가 동일하므로 병합은 수동이 아닌 구조적으로 이루어집니다. Q1, Q2, Q3, Q4의 행을 하나의 테이블로 쌓고, 출처를 보존하기 위해 분기 열을 추가한 후, 공급업체 내에서 날짜별로 정렬합니다. 그 결과 고객당 전체 회계 연도를 포괄하는 하나의 원장이 생성됩니다.

일반적인 Simpler BAS 고객의 원장 구조는 다음과 같습니다:

원장이 마련되면 검증은 두 가지 축으로 이루어집니다. 수평 축은 분기별 합계를 확인합니다. GST 열의 1분기 합계를 신고된 1B 수치와 대조합니다. 수직 축은 연간 일관성을 확인합니다. 공급업체별로 필터링하여 4개 분기 전체의 송장을 검토하고 분류 변경 사항을 표시합니다(동일 공급업체가 2분기에는 비자본으로 분류했으나 4분기에는 자본으로 분류한 경우). 분류가 변경된 이유는 구매 유형이 변경되어 정당한 경우이거나, 장부 담당자의 코딩이 변경된 경우입니다. 이제 원장을 통해 이를 확인할 수 있습니다.

회계사가 원장을 보기 전에 대부분의 오류를 잡아내는 실용적인 온전성 검사 방법: 분기별로 송장 합계 × (1 ÷ 11)가 총 GST 금액과 대략 일치해야 합니다. 카페의 3분기 송장 합계가 $12,100이고 GST가 $1,050인 경우, 1/11로 계산한 예상 GST는 $1,100입니다. $50 차이는 과세 대상이 아닌 비용이 잘못 포함되었거나, 과세 대상과 면세 구성 요소가 혼합된 공급 송장이거나, 추출 오류를 나타냅니다. 이를 표시하고 원본 문서를 확인한 후 수정하십시오. 이 검사는 분기당 30초가 소요되며, 차이가 연간 수치로 누적되는 것을 방지합니다.

다중 고객 배치: 하나의 워크플로로 30개 BAS 고객 처리

앞서 설명한 매트릭스 관리 과제(N 고객 × M 분기 × K 문서 유형)는 추출 스키마가 데이터 계층을 처리하고 장부 담당자가 조직 계층을 관리할 때 해결 가능해집니다. 분기별로 신고하는 30개 고객을 보유한 업무의 경우 워크플로는 다음과 같이 확장됩니다:

이를 기존 워크플로와 비교해 보겠습니다: 클라이언트 30곳 × 4분기 × 수동 데이터 입력 45분 = 연간 90시간을 PDF에서 스프레드시트로 숫자를 입력하는 데 소비합니다. 일괄 워크플로는 데이터 입력 부분을 분기당 클라이언트당 45분에서 약 3분으로 줄입니다. 이는 문서 업로드, 추출 실행, 출력 확인에 걸리는 시간입니다. 남은 시간은 더 가치 있는 작업, 즉 추출 결과 이상 여부 검토, 은행 명세서와 총액 대조, 클라이언트의 GST 상태에 대한 조언에 사용됩니다. 이는 BAS 에이전트가 등록된 본연의 업무이며, 그 선행 작업인 데이터 입력이 아닙니다.

동일한 일괄 통합 패턴은 여러 세무 관할권의 분기별 보고 시스템에도 적용됩니다. 여러 보고 기간에 걸쳐 하나의 추출 스키마를 사용하여 통합 원장을 생성하는 접근 방식은 호주 BAS에만 국한되지 않습니다. 영국 회계사들도 분기별 VAT 신고를 연간 계정에 반영하는 동일한 구조적 문제에 직면하며, 이는 영국 SA100 세금 신고 일괄 처리 가이드에서 다루고 있습니다. 또한 급여 팀은 PAYG 지급 요약을 연간 정산에 반영하는 문제에 직면하며, 이는 PAYG 지급 요약 일괄 처리 가이드에서 자세히 설명합니다. 추출 로직은 세법에 따라 변경되지만, 일괄 처리 원칙(하나의 스키마, 여러 기간, 하나의 통합 출력)은 그대로 적용됩니다.

BAS 회계 사무소의 EOFY가 어떻게 달라지는가

회계연도 말은 분기별 일괄 워크플로의 가치가 입증되는 시점입니다. 분기별로 정리된 데이터가 없으면, 30개 고객을 관리하는 부기 업무의 EOFY는 다음과 같습니다: 각 고객의 회계 파일을 열고, 연간 거래 보고서를 실행한 후 Excel로 내보내고, 각 거래에 BAS 레이블(G1, G10, G11, 1A, 1B)을 수동으로 태깅하고, 총액을 제출된 4개의 BAS 신고서와 조정한 후, 차이를 설명해야 합니다. 연간 거래가 200건인 고객의 경우, 태깅과 조정 작업만 2~3시간이 소요됩니다. 30개 고객을 기준으로 하면 60~90시간의 EOFY 작업이 필요하며, 이는 다음 분기 BAS 신고 기한이 겹치는 6월과 7월에 집중됩니다.

일괄 워크플로는 레이블 태깅이 조정 과정이 아닌 추출 과정에서 이루어졌기 때문에 이 단계를 대폭 단축합니다. 분기별 스프레드시트의 각 행에는 이미 BAS 레이블 매핑이 포함되어 있습니다. 4개 분기가 연간 원장으로 병합되면, 원장에는 연간 총 G1 매출, 총 G11 구매, 총 1B GST 공제가 이미 표시되므로 태깅 단계가 필요하지 않습니다. ATO의 GST 조정 프레임워크는 대규모 납세자가 BAS 결과를 감사 재무제표와 조정하도록 요구하며, 이러한 수준의 레이블별 연간 가시성을 기대합니다. Top 1000 납세자를 대상으로 하지 않는 회계 사무소의 경우에도 이 프레임워크는 올바른 원칙입니다: 모든 BAS 레이블을 연간 전체에 걸쳐 원본 문서까지 추적하고, 추출 총액이 제출된 수치와 다른 분기를 식별하는 것입니다.

실질적인 영향: 이전에는 부기 담당자의 6~7월 중 2~3주를 소비하던 EOFY가 검증 작업으로 전환됩니다. 각 고객의 연간 원장을 열고, 분기별 GST 온전성 검사를 실행하며, 이상 징후를 표시하고, 조정된 원장을 회계사에게 전달합니다. 회계사는 숫자를 검토할 뿐, 재구성하지 않습니다. 부기 담당자는 이미 완료되어야 할 데이터 입력이 아닌, 중요한 불일치 사항에 집중합니다.

자주 묻는 질문

일괄 추출 시 PDF 인보이스, 영수증 사진, 스캔한 BAS 양식을 같은 배치에서 함께 처리할 수 있나요?

가능합니다. 기본 비전 모델은 동일한 의미 로직으로 PDF, JPG, PNG 및 스크린샷의 텍스트를 읽습니다. Bunnings PDF 인보이스, 지역 공급업체의 필기 영수증 사진, 스캔한 BAS 사전 작성 양식이 포함된 배치도 모두 동일한 열 추출 스키마로 처리됩니다. AI는 각 필드의 의미를 이해하여 값을 찾습니다. PDF의 "Invoice Total"과 영수증에 적힌 "Total"은 형식이나 레이아웃에 관계없이 동일한 개념입니다. 이는 BAS 작업에서 특히 중요한데, 공급업체 인보이스는 대형 공급업체의 이메일 PDF, 현장에 남겨진 트레이드 인보이스의 휴대폰 사진, 종이 명세서를 받는 고객의 스캔 페이지 등 모든 형식으로 도착하기 때문입니다.

공급업체 인보이스에 GST 금액이 별도로 기재되지 않은 경우는 어떻게 하나요?

이는 $1,000 미만 금액에 대한 법적 최소 요건인 간이 세금 계산서를 발행하는 소규모 공급업체에서 발생합니다. 수동 계산 단계를 추가하는 대신 계산 열을 사용하세요. 열 이름을 GST 금액 (인보이스 합계 ÷ 11)로 지정하면 AI가 추출 중에 계산을 수행합니다. 이 공식은 GST 포함 합계에 대한 표준 10% 호주 GST에 유효합니다. 인보이스에 과세 대상과 면세 대상이 혼합된 경우(식품 및 건강 관련 사업에서 흔함) 해당 행에 플래그를 지정하고 수동으로 확인하세요. 계산 열은 표준 사례를 처리하고, 워크플로우는 배치 속도를 늦추지 않고 예외 사항을 수용합니다.

여러 고객을 대상으로 Xero의 BAS 모듈을 사용하는 것과 어떻게 비교되나요?

Xero의 BAS 모듈은 이미 Xero에 입력된 거래에 대해 작동합니다. 분류된 청구서와 인보이스에서 GST 합계를 가져와 BAS 양식을 채웁니다. PDF 공급업체 인보이스를 읽고 청구서를 생성하지는 않습니다. 30개의 Xero 조직을 관리하는 부기 담당자의 경우, 거래 데이터가 존재하면 모든 고객의 BAS 준비가 간소화됩니다. 문제는 소스 문서에서 해당 거래 데이터를 생성하는 것입니다. 각 고객마다 별도의 Xero 조직이 필요하며, 별도 로그인, 별도 Hubdoc 캡처(비표준 형식의 경우 수동 확인 필요), 별도 청구서 생성이 필요합니다. 일괄 추출 워크플로우는 데이터가 회계 소프트웨어에 도달하기 전에 단일 인터페이스에서 30개 고객의 모든 문서를 처리합니다. 두 도구는 순차적 단계를 처리합니다. 추출은 문서 → 구조화된 데이터를, Xero는 데이터 → BAS 신고를 담당합니다.

클라이언트가 BAS 제출을 밀려서 여러 분기를 한꺼번에 처리해야 하면 어떻게 하나요?

이런 경우 일괄 접근 방식의 구조적 장점이 가장 분명하게 드러납니다. 연체된 세 분기가 있는 신규 클라이언트의 경우 추출 스키마는 한 번만 정의합니다. 회계 담당자는 클라이언트가 제공할 수 있는 모든 문서를 세 개의 분기 폴더(Q1, Q2, Q3)로 정리하고, 각 폴더에 동일한 스키마를 실행하여 동일한 열을 가진 세 개의 구조화된 스프레드시트를 얻습니다. 그런 다음 세 분기를 병합하여 제출용 추후 정리 원장을 만들 수 있습니다. BAS 연체 시 흔히 발생하는 상황인 문서가 누락되거나 불완전한 경우, 원장을 통해 공백이 드러납니다. Q2에는 공급업체 송장 12개 행이 표시되는 반면 Q1에는 28개가 표시되어, 회계 담당자는 7월과 9월 사이에 무슨 일이 있었는지 클라이언트에게 물어볼 수 있습니다. 구조화된 원장이 없으면 누락된 문서는 일반적인 백로그에 섞여 있어 회계사가 EOFY 기록을 요청할 때까지 발견되지 않는 경우가 많습니다.

이 워크플로는 BAS 에이전트에 대한 TPB 요구 사항을 준수하나요?

세무사 협회(Tax Practitioners Board)는 BAS 에이전트가 각 BAS 제출을 뒷받침할 충분한 작업 문서를 유지하고 클라이언트의 상태를 파악하는 데 합리적인 주의를 기울일 것을 요구합니다. 일괄 워크플로는 두 요구 사항을 모두 지원합니다. 분기별 추출 스프레드시트는 각 BAS 레이블 수치가 어떻게 도출되었는지 보여주는 동시대 작업 문서이며, 각 행은 특정 원본 문서로 추적 가능합니다. 원장은 합리적인 주의를 입증하는 연간 조정 추적을 제공합니다. 에이전트는 각 분기 합계를 제출된 BAS와 대조하여 검토하고, 분류 일관성을 확인했으며, 모든 기간에 걸쳐 GST 계산이 일치하는지 검증했음을 보여줄 수 있습니다. 5년 문서 보관 요건은 추출 출력물을 원본 PDF와 짝지어 보관하는 폴더 구조를 통해 충족됩니다.

FBT 및 연료세 공제가 포함된 전체 BAS(Simpler BAS 아님)를 사용하는 클라이언트에게도 이 방식이 적용되나요?

네, 유일한 차이점은 추출 스키마의 열 개수입니다. FBT 할부금(F1), 연료세 공제(레이블 5A), 포도주 균등화세(레이블 5)가 있는 전체 BAS 클라이언트는 단순히 더 많은 열 정의가 필요합니다. 전체 BAS용 스키마에는 5~7개 대신 12~15개의 열이 포함될 수 있지만, 일괄 워크플로는 동일합니다. 스키마를 한 번 정의하고, 각 분기 문서에 적용한 후, 연간 원장으로 병합합니다. FBT 할부 금액(레이블 F1)은 일반적으로 ATO에서 계산하여 BAS 양식에 미리 인쇄되므로 원본 문서에서 추출하기보다는 F1 수치를 원장에 직접 입력합니다. 반면 연료세 공제는 문서 기반(연료 구매 영수증)이므로 연료세 공제 금액 열이 동일한 추출 과정을 통해 레이블 5A에 입력됩니다.

IAS(분할 납부 활동 명세서) 고객에게도 동일한 워크플로를 사용할 수 있나요?

네, 더 적은 열로 가능합니다. IAS는 GST 레이블 없이 PAYG 원천징수(W1, W2)와 PAYG 분할 납부금(T7)을 보고합니다. IAS 고객의 추출 스키마에는 일반적으로 총 임금(W1 입력), 원천징수 세액(W2), ATO 제공 분할 납부 금액(T7) 열이 포함됩니다. 레이블이 적어 배치 로직은 더 간단하지만, 분기별 데이터를 연간으로 병합하는 것은 동일하게 유용합니다. 특히 4개 IAS 기간의 총 PAYG 원천징수액이 연간 PAYG 지급 요약서와 일치하는지 확인하는 데 중요하며, 이는 일반적인 ATO 데이터 매칭 트리거 지점입니다.