미국은 멕시코·EU와 달리 전국 단위 전자세금계산서(e-invoice) 의무가 없습니다. 그래서 미국 세무의 핵심 과제는 계산서 인증이 아니라 판매·사용세(Sales & Use Tax)의 정확한 산정입니다. 주·카운티·시·특별구가 각각 과세권을 가지고 관할이 1만 개를 넘으며 세율·과세규칙이 수시로 바뀌기 때문에, SAP 내부 세율 테이블만으로는 유지가 불가능합니다. 본 글은 외부 세금엔진(External Tax Engine)을 SAP에 연동하는 접근을 실무 관점에서 정리한 참고 자료로, SAP 및 주요 세금엔진 벤더 공식 자료로 교차 검토했습니다. 세율·과세규칙·관할은 개정 주기가 짧으므로, 실제 설계 확정 전에는 대상 릴리즈 SAP Note와 선정 엔진 벤더 문서로 재검증해야 합니다.
1. 기본 개념 — 왜 외부 세금엔진인가
미국은 전국 단위 e-invoice 의무가 없으므로 핵심은 세액의 정확한 산정입니다. 과세관할(jurisdiction)이 2024년 기준 약 1.2만 개에 이르고 세율·과세대상 규칙이 수시로 바뀌기 때문에, 관할 결정과 세액 계산을 외부 세금엔진에 위임하는 것이 일반적입니다. 외부엔진이 세율·규칙 콘텐츠를 주기적으로 갱신해 준다는 점이 도입의 핵심 이유입니다.
SAP 연동 실무에서 자주 검토되는 상위 벤더는 Vertex, Avalara, Sovos(Taxware 사업 승계), Thomson Reuters ONESOURCE입니다. 특정 엔진으로 단정하기보다 고객 요건(거래 규모, 신고 범위, 배포 형태, 비용)에 맞춰 선정합니다. SAP 연동 방식(외부 세금 인터페이스)은 엔진과 무관하게 표준화되어 있어, 엔진을 바꿔도 인터페이스 골격은 유지됩니다.
SAP 외부 세금 처리 체인은 다음과 같습니다.
SAP(SD/MM/FI 문서) → Tax Interface(TAXUSX) → RFC/API → 외부엔진(Vertex/Avalara/Sovos 등) → 관할·세액 회신 → 전기 시 세금등록부 업데이트
| 용어 | 설명 |
|---|---|
| Sales Tax | 판매자가 최종소비자에게 징수·납부하는 판매세 |
| Use Tax | 판매세가 징수되지 않은 구매에 대해 구매자가 자진 신고·납부하는 사용세 |
| Nexus | 특정 주에 과세의무를 발생시키는 연결점(물리적·경제적 실재) |
| Jurisdiction Code | 과세 관할 식별코드. SAP 필드 TXJCD로 관리 |
| External Tax Engine | 관할 결정과 세액 계산을 담당하는 외부 시스템 |
단일단계 소매과세 (한국 부가세와의 차이)
한국 부가가치세는 유통 각 단계마다 부가세가 붙고 매입세액을 공제하는 다단계 방식입니다. 반면 미국 판매세는 최종소비자에게 판매되는 소매(retail) 거래 한 단계에서만 발생하는 단일단계 세금입니다. 중간 B2B 거래는 재판매 목적(sale for resale)이므로 면세증명서(resale certificate)를 근거로 과세되지 않습니다.
예를 들어 자동차 유통을 보면, 제조공장 → 판매법인, 판매법인 → 딜러(도매)까지는 재판매 목적이라 면세이고, 딜러가 최종소비자에게 파는 마지막 소매 거래에서만 판매세가 발생합니다. (단순화한 예시이며, 실제로는 주별 규칙·Use Tax 등 예외가 있습니다.) SAP 관점에서는 중간 거래를 재판매 면세로 처리하고 최종 소매 거래에서만 외부엔진이 과세하도록 고객 과세분류와 면세증명서를 설계합니다. 각 법인의 판매 성격(도매/소매)과 Ship-to 유형이 과세 판정의 기준이 됩니다.
2. 세금 유형 (Sales Tax vs Use Tax)
구현 범위를 잡을 때 먼저 식별해야 하는 축입니다.
| 유형 | 발생 시점 | 납세의무자 | SAP 매핑 |
|---|---|---|---|
| Sales Tax | 매출(판매) | 판매자가 징수·납부 | SD 청구, FI 매출전표 |
| Seller’s Use Tax | 주 간(inter-state) 원격 판매 | 판매자 | SD 청구 (원격거래) |
| Consumer Use Tax | 매입(구매) | 구매자가 자진 신고 | MM 송장검증(MIRO), FI 매입전표 |
Sales Tax는 Outbound(3장), Consumer Use Tax는 Inbound(4장)에서 다룹니다.
3. Outbound — 매출 세금 산정
자사 매출 거래의 세액을 외부엔진이 결정합니다. SD 가격결정(pricing) 또는 FI 전기 시점에 SAP가 외부엔진을 호출해 관할과 세액을 받아 문서에 반영합니다.
- SD 주문·청구 또는 FI 전표에서 세금 계산 시점 도달
- 관할 결정 — Ship-from / Ship-to 주소를 근거로 관할코드(TXJCD)를 확정합니다 (
RFC_DETERMINE_JURISDICTION) - 세액 계산 — 문서 라인 정보를 외부엔진에 전달해 세액을 회신받습니다 (
RFC_CALCULATE_TAXES_DOC) - 회신 세액을 조건유형(condition type)에 매핑해 문서에 반영
- 전기 시 세금등록부(감사파일) 업데이트 (
RFC_UPDATE_TAXES_DOC)
설계 시 고려할 지점은 다음과 같습니다.
- 주소 품질 — 관할 결정의 정확도는 주소 품질에 좌우됩니다. 주소 정제(address cleansing)와 우편번호 정합성을 확보합니다.
- 주소 축 정의 — Ship-from / Ship-to / Bill-to / Order-acceptance 등 관할 판정에 쓰이는 주소 축을 시나리오별로 정의합니다.
- 제품 과세성(product taxability) — 자재별 과세 여부·감면이 다르므로 자재마스터에 과세코드를 매핑합니다(9장 참조).
- 면세거래 — 면세증명서(exemption certificate) 보유 고객은 세액 0으로 처리합니다(8장 참조).
- 조건유형·세금코드(FTXP) — 외부엔진 사용 시 SAP 세금코드는 실제 세율을 갖지 않고 외부 회신값을 담는 틀로 동작합니다.
4. Inbound — 매입 / Consumer Use Tax
매입 거래에서 공급자가 판매세를 징수하지 않았거나 과소 징수한 경우, 구매자가 사용세(Use Tax)를 자진 신고·납부해야 합니다. SAP는 매입 문서(MIRO/FI)에서 외부엔진을 호출해 기대 세액을 산정하고, 공급자 청구 세액과 비교해 차액을 사용세로 자가 부과(self-assessment)합니다.
처리 관점은 매입 문서의 관할·과세성을 외부엔진으로 산정하고, 공급자 청구 세액과 산정 세액을 비교한 뒤, 미징수·과소징수분을 Consumer Use Tax로 자가 부과 전기하는 흐름입니다. 설계 시에는 사용세 자가부과 계정(accrual) 설계와 자동 전기 로직, 매입 시나리오별 과세성 판정(자재/서비스, 사용 목적), 면세·재판매(resale) 목적 매입의 예외 처리를 고려합니다.
5. 세금 등록부와 신고(Compliance)
외부엔진은 계산뿐 아니라 신고(returns) 근거가 되는 거래 이력을 축적합니다. 전기 시점에 SAP가 세금등록부/감사파일을 업데이트하고, 이 데이터가 월별 신고와 감사대응의 원천이 됩니다.
- 세금등록부 업데이트 — 전기 확정 시
RFC_UPDATE_TAXES_DOC로 외부엔진 등록부에 기록합니다. 견적·시뮬레이션 호출과 실제 전기 호출을 구분해야 등록부가 이중 기록되지 않습니다. - 신고(returns) — 산정된 거래 데이터를 근거로 주·지방별 신고서를 작성합니다. 엔진 벤더가 신고·송부(filing) 기능을 별도 제공하기도 합니다.
- 감사대응 — 관할별 세액 산출 근거와 면세증명 연결을 추적 가능하게 보관합니다.
시뮬레이션(계산 전용) 호출과 확정(업데이트) 호출의 분리 원칙을 준수하고, 신고를 SAP 외부(엔진 측)에서 수행할지 SAP 리포팅과 병행할지 범위를 확정합니다.
6. 구현 방식 옵션 (SAP 표준 인터페이스 vs 커넥터·배포 형태)
외부엔진 연동은 SAP 표준 세금 인터페이스를 공통 기반으로 하되, 엔진 배포 형태와 커넥터 방식에 따라 구성이 나뉩니다.
- On-Premise 엔진 + RFC 커넥터 — 엔진을 온프레미스로 두고 SAP RFC Destination(연결유형 T, TCP/IP, Program ID)으로 커넥터에 연결합니다. SM59에서 설정합니다.
- Cloud 엔진 + API/커넥터 — 클라우드 세금결정 서비스에 파트너 커넥터(또는 API)로 연결합니다. S/4HANA에서는 SAP 인증 파트너 커넥터를 통한 연동이 일반적입니다.
- SAP S/4HANA Cloud 표준 연동 — 표준 외부 세금결정(External Tax Determination) 시나리오로 파트너 서비스와 연결합니다.
SPRO 기준 주요 설정 항목은 다음과 같습니다(대상 릴리즈로 재확인). Tax Procedure 배정(미국 TAXUSX), Jurisdiction Code 구조 지정(엔진·커넥터별 상이), External Tax Calculation 활성화(External System·Interface Version·RFC Destination 연결), External Updating 활성화(세금등록부 실시간 업데이트), 세금코드 유지(FTXP, 외부 회신값을 받는 구조), 비과세 기본 관할(OBCL) 지정. 세부 파라미터 값은 엔진·커넥터·릴리즈에 따라 달라지므로 선정 엔진의 구성 가이드와 SAP Note로 확정합니다.
7. 거래 유형별 필수 정보
공통적으로 관할 판정을 위한 정확한 주소(Ship-from/Ship-to 등), 자재 과세코드, 고객 과세분류(면세 여부), 거래 금액이 필요합니다. 관할·과세성 판정 결과가 세액을 좌우합니다.
주내(intra-state) 판매 — Ship-from과 Ship-to가 같은 주로, 해당 주·지방 관할의 판매세가 적용됩니다. SAP 관점에서는 사업장(plant)·고객 주소의 정합성과 관할코드 정확성이 핵심입니다.
주간(inter-state) 원격 판매 — Ship-to 주에 Nexus가 있으면 그 주의 세금(주로 Seller’s Use Tax)이 적용됩니다. Nexus 판단이 선결 조건이며, SAP 관점에서는 Nexus 등록 주 정보를 엔진 측에 유지하고 회사코드/판매조직별 Nexus 프로파일을 반영합니다.
면세거래 — 재판매(resale), 제조원자재, 비영리·정부 등 면세 사유가 있는 거래로 유효한 면세증명서가 전제됩니다. 고객 과세분류와 면세증명 연결로 세액 0을 처리하고 증명서 유효기간·관할 범위를 관리합니다.
매입(Use Tax) — 공급자가 세금을 징수하지 않은 과세 대상 매입으로, 구매자가 사용세를 자가 부과합니다(4장 참조).
8. 알아둘 특수 개념
Jurisdiction Code (관할코드 / TXJCD) — 과세 관할을 식별하는 코드로 SAP 필드 TXJCD에 저장됩니다. 주·카운티·시·특별구가 계층으로 결합된 구조이며 주소로부터 결정됩니다. 세액 계산의 출발점이자 신고 집계의 기준입니다. 캐나다도 미국과 유사한 TAXUSX/TXJCD 체계를 공유하지만, 브라질은 주+시(IBGE) 코드 기반의 별도 로컬라이제이션 구조를 사용하므로 미국식 외부엔진 모델과 동일선상에 두기 어렵습니다. 미국은 관할 수가 방대하고 변동이 잦아 외부엔진에 의존합니다. 정확한 주소(ZIP·도로명)가 올바른 관할을 결정하므로, 세무 이슈를 막으려면 정확한 주소 관리가 선행 필수입니다.
Nexus — 특정 주에 대해 과세의무를 발생시키는 연결점입니다. 과거에는 물리적 실재(사무소·창고·인력) 중심이었으나, 2018년 미 연방대법원 South Dakota v. Wayfair 판결로 물리적 실재 원칙이 파기된 이후에는 매출액·거래건수 기준의 경제적 Nexus(economic nexus)도 널리 적용됩니다. Nexus가 없는 주에는 징수의무가 없으므로, Nexus 프로파일이 세액 판정의 전제가 됩니다.
Product Taxability Code (제품 과세코드) — 품목의 과세성(과세/비과세/감면/특례)을 엔진이 판단하도록 부여하는 분류코드입니다. 동일 품목도 주별로 과세성이 다를 수 있어, 엔진의 과세코드 체계에 SAP 자재를 매핑해야 합니다.
Exemption Certificate (면세증명서) — 고객의 면세 자격을 증빙하는 문서입니다. 재판매·제조·정부·비영리 등 사유별로 발급되며 관할·유효기간이 한정됩니다. 증명서 관리 기능은 엔진 벤더가 제공하기도 하며, SAP에서는 고객 과세분류와 연결해 면세 처리합니다.
Situs (과세지) — 과세권이 귀속되는 장소입니다. Ship-to 기준(destination-based)인지 Ship-from 기준(origin-based)인지는 주 규칙에 따라 다르며(대부분 destination-based이나 텍사스 등 일부 주는 지방세에 origin-based 적용), 관할 판정 주소 축 설계에 영향을 줍니다.
9. 코드 체계 (SAP 세금코드 vs 엔진 코드)
미국 외부세금 구현에서는 성격이 다른 코드를 구분해야 합니다.
SAP Tax Code(FTXP) 는 SAP 문서에 붙는 세금코드로, 외부엔진 사용 시 실제 세율을 보유하지 않고 외부 회신값을 담는 틀로 동작하며 조건유형·계정결정과 연결됩니다. Tax Jurisdiction Code(TXJCD) 는 과세 관할 식별코드로 주소로부터 결정되며 세액 계산·신고 집계의 기준입니다. Engine Product/Tax Code 는 외부엔진이 과세성 판단에 사용하는 자체 제품·거래 코드로, SAP 자재·거래를 이 코드에 매핑합니다.
| 구분 | SAP Tax Code | Jurisdiction Code(TXJCD) | Engine Product Code |
|---|---|---|---|
| 주체 | SAP | SAP(주소 기반) | 외부엔진 |
| 역할 | 회계처리 틀·조건유형 연결 | 관할 식별·신고 집계 | 과세성 판정 |
| 세율 보유 | 아니오(외부 회신) | 해당 없음 | 엔진 콘텐츠가 보유 |
자재마스터·고객마스터의 과세분류를 엔진 코드 체계에 정확히 매핑해야 하며, 매핑 누락은 과세성 오판정으로 직결되므로 신규 자재·고객 등록 시 검증 통제를 둡니다. 엔진의 재화·서비스 코드(GSID 등)를 SAP에 부여하는 방법은 여러 가지이나, 기본은 FTXP에서 세금코드에 할당하는 방식입니다. 이 할당 필드는 국가 설정의 세금 프로시저가 TAXUSX일 때만 열립니다.
10. SD/MM/FI 모듈별 세금 처리
FI와 MM은 기본적으로 국가에 설정된 세금 프로시저(TAXUSX)를 사용합니다. SD는 FI에서 설정한 컨디션을 그대로 채용할 수도, 독립적으로 세팅할 수도 있습니다. 컨디션 매핑 관점에서 FI 전표의 Base amount는 SD 샘플 컨디션 상 UTXD에 해당하고, SD 전표(빌링)의 UTXE 값이 외부엔진 인터페이스에 사용됩니다.
외부엔진 사용 시 매출 세금코드의 조건유형은 실제 세율 대신 엔진이 계산한 회신값을 100% 수용하는 구조로 세팅합니다. 즉 SAP는 세율을 직접 갖지 않고 엔진 산출값을 그대로 반영합니다. 매출 세금 조건유형(XR1~XR6 등 복수 단계)이 여러 개인 이유는 세율이 주·카운티·시 등 여러 관할 레벨에서 발생하기 때문입니다.
아래는 관할 레벨 매핑의 한 예시입니다. 정확한 조건유형 개수·명칭·레벨 매핑은 사용 엔진(Vertex/Avalara/Sovos/ONESOURCE)과 SAP 버전·커넥터에 따라 달라지므로, 선정 엔진의 구성 가이드로 확정해야 합니다.
| 컨디션(예시) | 관할 레벨(예시) |
|---|---|
| XR1 | State |
| XR2 | County |
| XR3 | City |
| XR4 | District / Local |
| XR5 | 추가 지방 레벨 |
| XR6 | (구현별 사용/미사용) |
11. GSI 환경 고려사항과 SAP 표준 제약
GSI(Global Single Instance)는 다수 국가·법인이 하나의 SAP 시스템/클라이언트(MANDT)를 공유하는 구조입니다. 외부 세금엔진을 이 환경에 얹을 때 SAP 표준의 제약이 드러나며, 대부분 Enhancement로 보완해야 합니다.
- 주소 소스의 한계 — SAP External Tax Engine은 기본적으로 KNA1(고객마스터)·LFA1(공급업체마스터)의 국가·주소 정보를 관할 판정에 사용합니다. 회사코드 등 조직 단위로 특화된 주소를 별도 관리해야 하는 경우, 표준 인터페이스가 이를 반영하지 못하므로 별도 Enhancement가 필요합니다.
- 단일 클라이언트 혼재 — 판매세가 거의 없고 사용세도 정형화된 법인(예: 제조공장)과 세금엔진을 본격 사용하는 법인이 공통 클라이언트(MANDT)를 공유하면, 세금 처리 방식이 상이한 법인들이 동일한 표준 인터페이스를 타게 됩니다. 이 경우 상호 호환성 확보를 위한 Enhancement가 불가피합니다.
- SaaS 벤더의 범위 한계 — SaaS 기반 세금엔진 벤더는 이러한 SAP 측 Enhancement를 제공하지 않습니다. 엔진 콘텐츠·API는 제공하되, 고객 SAP 내부의 주소·조직 특화 로직은 고객 책임 영역입니다. 따라서 해당 Enhancement를 설계·구현할 전문인력 확보(채용 또는 전문 컨설팅)가 필수입니다.
정리하면, GSI에서 외부 세금엔진은 표준 연결만으로 끝나지 않습니다. 조직별 특화 주소와 다법인 단일 클라이언트 혼재를 다루는 Enhancement 범위를 착수 초기에 식별하고, 이를 수행할 SAP 전문인력을 확보하는 것이 리스크 관리의 핵심입니다.
12. Tax By-pass (레거시 확정 세액 처리)
구매포털·판매시스템 등 레거시 시스템에서 Tax를 포함한 분개정보가 이미 확정되어 SAP로 전달·처리해야 하는 경우가 있습니다. 이때 SAP가 외부 세금엔진을 다시 호출하면 값이 어긋나거나, BDC(Batch Data Communication)로 전표를 처리하는 과정에서 오류가 발생합니다.
외부엔진 재계산을 우회하려면, 영세(zero) 세금코드를 사용하고 Sales & Use Tax 라인을 직접 생성해 확정 세액을 그대로 전기합니다. SAP가 세액을 재계산하지 않고 레거시 확정값을 반영하도록 하는 방식입니다. 다만 세금코드를 “외부세금 비관련”으로 지정하는 T007A-TXREL/TXIND 필드를 두더라도 SAP가 이를 참조하지 않아 외부 세금엔진이 여전히 호출되는 사례가 보고됩니다(SAP KBA 3425446 — TXREL=‘2’여도 외부세금 시스템 호출, 에러 FS861). 따라서 이들 필드에 의존한 by-pass 제어는 신뢰하기 어려우며, 영세코드와 세금라인 직접 생성 방식이 실무적 대안입니다.
13. 해외 본사의 미국 롤아웃과 한국 전문 컨설팅의 역할
미국 외에 본사를 둔 기업(예: 한국)이 미국 법인을 롤아웃/롤인할 때는, 현지 구축업체와 세금엔진 벤더만으로 채워지지 않는 영역이 있습니다. 본사 측 언어·업무·글로벌 템플릿을 이해하는 한국 전문 컨설팅이 세 주체(한국 컨설팅·현지 구축업체·엔진 벤더) 사이에서 다음을 담당합니다.
- 프로세스 정합 및 To-Be 조율 — 고객사 프로세스를 파악해 To-Be 시스템 기준으로 현지 구축업체와 조율하고, 본사 표준과 현지(주별) 요건 간 격차를 해소합니다.
- 기준정보 중계 — 재화·용역, BP 마스터, 자재 과세코드 등 본사 특화가 있는 경우 현지 구축에 반영하도록 중계합니다.
- PM Focal — WBS 관리 등 프로젝트 관리 접점 역할로 일정·범위·이슈를 본사–현지 간에 통제합니다.
- 트러블슈팅 — 관할 오판정, 세액 불일치, 엔진 커넥터 오류 등을 현지 구축업체·엔진 벤더와 공동 분석·해소하고, 본사 측이 맥락을 이해하도록 연결합니다.
14. 착수 체크리스트
- 솔루션 스택 — S/4HANA 릴리즈, 세금엔진(Vertex/Avalara/Sovos/ONESOURCE 등 선정) 및 배포형태(On-prem/Cloud), 커넥터 방식
- Tax Procedure — TAXUSX(미국)
- 연결 설정 — RFC Destination(SM59) 또는 파트너 커넥터/API, Interface Version, External System
- Jurisdiction — 관할코드 구조, 주소 정제, 관할 판정 주소 축
- Nexus 프로파일 — 등록 주와 경제적 Nexus 기준
- 마스터데이터 — 자재 과세코드, 고객 과세분류·면세증명, 사업장/고객 주소
- 시나리오 범위 — 매출(Sales/Seller’s Use), 매입(Consumer Use), 면세, 주간 원격판매
- 세금등록부·신고 범위 — 업데이트 호출 원칙, 신고를 엔진/SAP 중 어디서 수행할지
- 운영 모니터링 — 관할·세액 오류 처리, 콘텐츠(세율) 갱신 반영, 면세증명 만료 관리
- 세금코드·컨디션 세팅(9~10장) — 매출 세금코드의 회신값 100% 수용 구조, SD 컨디션(UTXD/UTXE) 매핑, 재화/서비스 코드 세금코드 할당
- GSI 제약 대응(11장) — 조직별 특화 주소, 다법인 단일 클라이언트 혼재에 따른 인터페이스 Enhancement 범위 식별 및 전문인력 확보
- Tax by-pass 대상(12장) — 레거시 확정 세액 전표의 영세코드·세금라인 직접 생성 처리 방식 정의
15. 착수 시 재검증 항목
단정하지 않고 착수 시점에 원천 확인이 필요한 항목입니다.
- 외부 세금결정 설정 파라미터(구조값·Interface Version·활성화 옵션)의 대상 릴리즈 정확값 → SAP Note 및 선정 엔진 구성 가이드
- 선정 엔진의 제품 라인업과 SAP 인증 커넥터 현행 버전 → 각 벤더 및 SAP 파트너 자료
- 경제적 Nexus 기준(주별 매출·건수 임계치)의 최신값 → 각 주 세무당국
- 관할 판정 주소 축(destination vs origin)의 주별 규칙 → 각 주 세무당국
- 사용세 자가부과 자동화의 SAP 표준 지원 범위 → 대상 릴리즈 SAP Note
- 조건유형(XR1~XR6 등) 레벨 매핑 및 by-pass 동작의 대상 릴리즈 적용 여부 → 선정 엔진 구성 가이드 및 SAP KBA 3425446·3204600
결론
미국 세무는 “계산서를 인증받는” 문제가 아니라 “정확한 관할과 세액을 산정하는” 문제입니다. 1만 개가 넘는 관할과 수시로 바뀌는 규칙을 SAP 내부에서 감당할 수 없기에, 외부 세금엔진 연동이 사실상 표준이 됩니다. 다만 표준 인터페이스로 연결하는 것만으로 끝나지 않습니다 — 관할 판정의 주소 품질, Nexus 프로파일, 면세증명 관리, 그리고 GSI 환경의 조직별 특화 주소·다법인 혼재를 다루는 Enhancement가 실제 성패를 가릅니다.
도상 컨설팅팀은 해외 본사의 미국 롤아웃에서 본사–현지–엔진 벤더 사이의 프로세스 정합과 트러블슈팅, 그리고 SAP 표준 제약을 보완하는 Enhancement 설계를 담당하는 한국 전문 컨설팅 역할을 수행합니다. 미국 법인 구축·전환을 검토 중이시라면 범위 산정 단계의 진단 세션을 별도로 안내드립니다.
본 분석은 일반 정보 제공을 목적으로 하며, 개별 거래의 세무·법무 자문이 아닙니다. 미국 판매·사용세 규칙과 SAP 설정값은 주별·릴리즈별·엔진별로 상이하고 개정 주기가 짧으므로, 의사결정 및 설계 확정 전 각 주 세무당국·대상 릴리즈 SAP Note·선정 엔진 벤더 문서·현지 세무 검토를 권고합니다. 규제·기술 사실은 SAP 및 주요 세금엔진 벤더 공식 자료를 기준으로 교차 검토했습니다(2026-07-20 기준).