호주 BAS 4개 분기를
하나의 연간 세무 원장으로 일괄 처리하는 방법

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

Simpler BAS 방식으로 단일 고객을 위해 준비하는 분기별 BAS 하나에는 GST 라벨 3개(G1, 1A, 1B)와, 직원이 있는 사업체라면 PAYG 원천징수 필드 2개(W1, W2)가 포함됩니다. 해당 라벨 뒤에 있는 문서들 — 공급업체 인보이스 15~25장, 조정용 은행 명세서, 급여 요약 — 을 정리하고 검증하는 데 30~45분이 걸립니다. 그 숫자는 합리적으로 느껴집니다. 대부분의 부기 담당자가 이 워크플로에 의문을 제기하지 않는 이유입니다. 고객당 분기별 45분은 연간 고객당 3시간이 되며, 시간당 $100~$150의 청구 요율로 계산하면 연간 $300~$450에 해당합니다. 감당할 수 있는 수준입니다.

규모가 커지면 산술이 달라집니다. 분기별 신고 고객 30명을 둔 BAS 에이전트는 연간 120건의 BAS 기간을 처리합니다. 각각 45분씩이면 문서에서 스프레드시트 행으로 숫자를 옮기는 데 90시간 — 즉 완전한 근무 주 2주 — 가 소요됩니다. 그리고 이는 최상의 경우입니다. 모든 공급업체 인보이스가 GST 금액이 명확히 표시된 일관된 형식으로 도착하고, 모든 은행 명세서가 첫 시도에 조정되며, 신고를 미뤄서 과거 BAS 기간을 재구성해야 하는 고객이 없다고 가정할 때입니다.

대부분의 부기 업무 현장의 현실은 ASBFEO 조사 결과에 더 가깝습니다. 중소기업의 39%가 규제 준수에 주당 6시간 이상을 소비하며, BAS 신고가 그 부담의 중심에 있습니다. 신규 고객이 연체된 분기 3개를 안고 도착하면, 부기 담당자는 BAS 하나를 처리하는 것이 아니라 4개를 처음부터 처리하는 셈이며, 9개월에 걸친 혼합 형식의 원본 문서를 다루게 됩니다. 시간은 배가되지만 열은 변하지 않습니다. ATO 라벨은 4월이나 7월이나 동일합니다. 변하는 것은 입력 문서의 양이지 출력 구조가 아닙니다.

단일 분기 추출 방식 — 자세한 내용은 단계별 AU BAS 추출 가이드에서 다룹니다 — 은 자신의 분기별 BAS를 직접 처리하는 사업주에게 완벽하게 작동합니다. 연간 120건의 BAS 기간을 처리하는 부기 담당자에게 병목은 분기별 추출 로직이 아닙니다. 문제는 동일한 추출 로직을 서로 다른 고객의 서로 다른 문서 세트에 적용해야 하고, 4개 분기의 결과가 각 고객의 하나의 일관된 연간 원장으로 수렴해야 한다는 사실입니다. Q1, Q2, Q3, Q4를 회계사가 EOFY에 ATO에 제출할 수 있는 단일 세무 원장으로 병합하는 이 수렴 단계에서 대부분의 워크플로가 무너집니다.

북키퍼에게 배치 BAS 처리가 실제로 의미하는 것

이 맥락에서 배치 처리는 한 번에 하나씩 업로드하는 대신 50개 파일을 한 번에 업로드하는 것에 관한 것이 아닙니다. 물론 그것도 일부이긴 합니다. BAS 북키핑의 배치 과제는 매트릭스 관리입니다. N명의 고객이 있고, 각 고객마다 M개의 분기별 BAS 기간이 있으며, 각 기간은 K가지 출처 문서 유형에서 데이터를 가져옵니다. 고객 30명을 관리하는 북키퍼는 30 × 4 × 4 = 480개 문서 유형 매트릭스를 관리하는 셈입니다. 이 매트릭스의 출력 측면은 고객별·분기별 구조화된 숫자 집합이며, 이 모든 숫자는 궁극적으로 연간 세금 원장으로 통합되어야 합니다.

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

이때 맞춤 열 추출 — AI가 각 필드의 의미를 이해하여 문서의 위치가 아닌 의미를 기준으로 일치하는 데이터를 찾는 데 사용하는 열 이름 집합을 정의하는 것 — 이 구조적 해결책이 됩니다. 북키퍼가 공급업체 이름, 인보이스 합계, GST 금액, 구매 유형 같은 열을 고객별로 한 번 정의하면 모든 분기의 모든 문서가 동일한 의미 추출 로직으로 처리됩니다. Q1의 Bunnings 인보이스와 Q3의 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 클라이언트의 경우 수출 매출, GST 면제 매출(G3), 급여 요약을 추출하는 경우 PAYG 항목(W1, W2)에 대한 열을 추가하세요. 핵심 설계 원칙: 모든 열은 BAS 항목에 매핑되고, 클라이언트의 BAS에 표시되는 모든 항목에는 해당 열이 있습니다. 열이 없으면 해당 항목의 데이터가 원장에서 누락되며, 조정 전까지 이를 알 수 없습니다.

스키마는 재사용 가능한 구성으로 저장됩니다. ATO 항목이 변경되지 않으므로 열 이름과 데이터 유형은 분기 간에 변경되지 않습니다. Q1과 Q2 사이에 변경되는 것은 소스 문서 세트이지 추출 로직이 아닙니다. 카페 클라이언트의 스키마는 10월, 2월, 4월, 7월에 동일하게 적용됩니다. 추출 도구는 각 문서를 읽고 각 열 정의와 일치하는 값을 찾아 동일한 구조의 테이블로 출력합니다. 10월~12월 분기의 공급업체 인보이스 40장은 1월~3월 분기의 인보이스 35장과 동일한 열로 40개의 행을 생성합니다. 구조는 규율이 아닌 설계에 의해 일관됩니다.

2단계: 클라이언트 및 분기별 문서 일괄 처리

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

추출 계획을 반영한 폴더 구조로 원본 문서를 정리합니다:

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

각 일괄 실행의 출력은 단일 스프레드시트로, 각 행은 원본 문서 하나를 나타내고 각 열은 BAS 라벨에 매핑됩니다. 카페 고객의 1분기 출력은 공급업체 이름, 송장 합계, GST 금액, 구매 유형 열로 구성된 표입니다. 2분기 출력도 동일한 구조입니다. 3분기와 4분기도 마찬가지입니다. 고객당 동일한 구조의 스프레드시트 4개 — 이는 다음 병합 단계의 전제 조건입니다.

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

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

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

원장이 준비되면 검증은 두 축을 따라 진행됩니다. 가로 축은 분기별 합계를 확인합니다. Q1의 GST 열을 합산하여 신고된 1B 수치와 대조합니다. 세로 축은 연간 일관성을 확인합니다. 공급업체별로 필터링하여 4개 분기 전체의 인보이스를 검토하고 분류 변경 사항을 표시합니다. 구매 유형이 변경되어 분류가 바뀌었을 수도 있고 — 이는 정당한 경우입니다 — 또는 회계 담당자의 코딩이 어긋났을 수도 있습니다 — 이제 원장을 통해 확인할 수 있습니다.

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

멀티 클라이언트 일괄 처리: 하나의 워크플로우로 BAS 클라이언트 30곳 운영

앞서 설명한 매트릭스 관리 과제 — 클라이언트 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 합리성 검사를 실행하고, 이상 징후를 표시하고, 조정된 원장을 회계사에게 전달하면 됩니다. 회계사는 숫자를 재구성하는 것이 아니라 검토합니다. 부기 담당자는 이미 완료되어야 할 데이터 입력이 아닌 중요한 불일치에 집중합니다.

FAQ

한 배치에서 PDF 인보이스, 영수증 사진, 스캔한 BAS 양식을 혼합하여 추출할 수 있나요?

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

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

이런 경우는 $1,000 미만 금액에 대한 법적 최소 기준인 간이 세금 인보이스를 발행하는 소규모 공급업체에서 발생합니다. 수동 계산 단계를 추가하는 대신 계산 열을 사용하세요. 열 이름을 GST Amount (Invoice Total ÷ 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)로 정리하고, 각 폴더에 동일한 스키마를 적용하여 동일한 열 구조의 스프레드시트 세 개를 얻습니다. 그런 다음 세 분기를 합쳐 신고를 위한 누락분 장부를 만들 수 있습니다. 문서가 누락되었거나 불완전한 경우 장부 덕분에 누락된 부분이 드러납니다. Q2에는 공급업체 인보이스가 12건인 반면 Q1에는 28건으로 표시되므로, 부기 담당자는 7월에서 9월 사이에 무슨 일이 있었는지 고객에게 물어봐야 한다는 것을 알 수 있습니다. 구조화된 장부가 없으면 누락된 문서는 일반적인 밀린 업무에 섞여 버리고, 회계사가 연말(EOFY) 기록을 요청할 때까지 발견되지 않는 경우가 많습니다.

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

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

FBT 및 유류세 환급이 포함된 전체 BAS 고객에게도 적용되나요?

네 — 유일한 차이는 추출 스키마의 열 수입니다. FBT 분할납부(F1), 유류세 환급, 와인 균등화세가 있는 전체 BAS 고객은 열 정의가 더 많을 뿐입니다. 전체 BAS용 스키마는 5~7개 대신 12~15개 열을 포함할 수 있지만, 일괄 워크플로우는 동일합니다. 스키마를 한 번 정의하고 각 분기 문서에 적용한 후 연간 장부로 병합합니다. FBT 분할납부 금액은 일반적으로 ATO가 계산하여 BAS 양식에 미리 인쇄되며 출처 문서에서 도출되지 않습니다. 이 경우 F1 수치는 추출하는 대신 장부에 직접 입력합니다. 반면 유류세 환급은 문서 기반이므로 유류세 환급 금액 열이 동일한 추출 프로세스를 통해 라벨 5A에 반영됩니다.

IAS 고객에게도 동일한 워크플로를 사용할 수 있나요?

네, 열 수가 적을 뿐 동일하게 사용할 수 있습니다. IAS는 GST 라벨 없이 PAYG 원천징수(W1, W2)와 PAYG 분할 납부액(T7)을 보고합니다. IAS 고객을 위한 추출 스키마에는 일반적으로 총 임금, 원천징수 세액(W2), ATO 제공 분할 납부액(T7) 열이 포함됩니다. 라벨 수가 적어 일괄 처리 로직은 더 간단하지만, 분기별 데이터를 연간으로 통합하는 작업은 그만큼 가치가 있습니다. 특히 4개 IAS 기간의 총 PAYG 원천징수액이 연간 PAYG 납부 요약과 일치하는지 확인하는 데 유용하며, 이는 ATO 데이터 매칭의 일반적인 트리거 지점입니다.