글: Kristijan Sekereš

2027년 오만 Fawtara 전자 인보이스: 자체 ERP와 POS 시스템에 필요한 것

산을 등지고 있는 무스카트의 무트라 해안

오만은 종이와 PDF 인보이스를 구조화된 XML 전자 인보이스로 바꾸고 있습니다. 이 인보이스는 공인 서비스 제공자를 거쳐 오만 세무청(OTA)에 보고됩니다. 프로그램의 이름은 Fawtara입니다. 연간 공급액이 500만 리알(OMR)을 넘는 납세자는 2027년 4월 1일에 시작합니다. 그 밖의 모든 VAT 등록 납세자는 2027년 10월 1일에 시작합니다.

가장 크게 영향을 받는 곳은 소매업입니다. 소비자 대상 판매는 사업자 대상 판매와 같은 날부터 적용되며, 판매 한 건 한 건마다 별도의 전자 인보이스가 필요합니다. POS 소프트웨어, ERP, 과금 엔진을 사내에서 만들었거나 대폭 커스터마이징했다면 그 문서를 만들어 내는 작업은 귀사의 몫입니다.

일정과 귀사에 해당하는 날짜

출처는 2026년 8월 31일에 마지막으로 갱신된 OTA의 Fawtara FAQ입니다. 기준은 분명하게 제시되어 있습니다. 다음 중 하나에 해당하면 2027년 4월 1일부터 시행해야 합니다.

  • 2026년 4월 1일부터 2027년 3월 31일까지의 공급액이 500만 리알을 넘는 경우
  • 2027년 4월 1일부터 2028년 3월 31일까지의 예상 공급액이 500만 리알을 넘는 경우

"둘 다 해당하지 않으면 2027년 10월 1일부터 전자 인보이스를 시행해야 합니다."

금액에 포함되는 것은 과세 공급이며, 자본 자산, 역과세(reverse charge) 대상 재화와 서비스, GCC 역내 공급은 제외됩니다. VAT 그룹은 구성원별이 아니라 그룹 단위로 판단합니다. 비거주자는 오만에서 이루어진 공급만 계산합니다.

두 번째 요건에 주목하십시오. 500만 리알을 향해 성장 중인 사업자는 예측치만으로도 4월 그룹에 들어갈 수 있습니다. 기준선 근처라면 4월이라고 가정하십시오.

OTA는 시행 시기 확인 도구를 운영합니다. VATIN과 현재 및 예상 공급액 구간을 입력하면 예상 시행 시기를 보여 줍니다. 이 도구는 인지와 준비를 위한 것이라고만 표시되어 있으니, 그 답은 참고로 삼고 규칙은 FAQ를 따르십시오.

일정은 이미 한 번 바뀌었습니다

OTA의 HTML FAQ 페이지는 여전히 예전 계획을 설명합니다. 2026년 8월부터 대기업 100곳, 2027년 2월부터 모든 대기업, 2027년 8월부터 나머지 전부입니다. PDF는 이 날짜들을 2027년 4월과 10월로 바꿉니다. 선정된 대형 납세자로 이루어진 첫 그룹(Rollout 1)에는 2026년 8월이 공식 시행일로 남아 있으며, 파일럿의 일환으로 2026년 10월 말까지 유예 기간이 있습니다.

PDF의 일정 부분에 있는 한 문장은 500만 리알 초과 사업자의 의무 준수가 "April 1st 2026"부터라고 적고 있습니다. 같은 문서의 다른 곳은 위에 인용한 상세한 적용 범위 답변을 포함해 모두 2027년 4월 1일이라고 말합니다. 오기로 보이지만, 누구의 요약(저희 요약 포함)이 아니라 1차 문서를 기준으로 일해야 할 좋은 이유입니다.

Fawtara의 작동 방식

Fawtara는 5-코너 모델을 사용하는 Peppol 위에서 돌아갑니다.

  1. 코너 1: 판매자인 귀사가 인보이스를 발행합니다.
  2. 코너 2: 귀사의 공인 서비스 제공자(ASP)가 오만 규칙에 따라 인보이스를 검증하고 전달합니다.
  3. 코너 3: 구매자의 서비스 제공자가 인보이스를 받습니다.
  4. 코너 4: 구매자.
  5. 코너 5: 서비스 제공자들로부터 세무 데이터를 받는 OTA.

형식은 OpenPeppol이 공개하는 PINT Oman 사양(이 글을 쓰는 시점에 Billing Process 버전 1.0.1)에 따라 만든 XML입니다. FAQ는 "PDF 인보이스는 전자 인보이스가 아니다"라고 단호하게 말합니다. 종이로 인쇄할 수는 있지만 세무상 유효한 인보이스는 전자 인보이스뿐입니다.

FAQ의 세 가지 세부 사항이 엔지니어링을 좌우합니다.

  • 서비스 제공자가 검증하지만 책임은 귀사에 남습니다. ASP는 각 인보이스를 오만 schematron 규칙으로 점검하지만, "인보이스 규정 준수에 대한 책임은 납세자에게 남아 있습니다".
  • 한 번에 한 서비스 제공자와만 연결합니다. 연결은 Fawtara 포털에서 요청하며 나중에 바꿀 수 있습니다.
  • 표준 납세자 API는 없습니다. FAQ의 표현으로는 납세자 연결이 "표준화되어 있지 않으며 서비스 제공자의 시스템에 따라 다릅니다". ERP는 OTA가 아니라 서비스 제공자의 인터페이스와 통신합니다.

구매자가 소비자이거나 아직 네트워크에 들어오지 않은 사업자라도 서비스 제공자는 세무 데이터를 OTA에 보고하고, 고객은 지금처럼 인보이스를 받습니다. 수출은 귀사에서 서비스 제공자를 거쳐 OTA로 갑니다.

이미 해결된 경우

ERP나 POS 벤더가 직접 공인 서비스 제공자이거나 공인 서비스 제공자와의 커넥터를 제공한다면, 이 글의 대부분은 귀사의 문제가 아닙니다. FAQ는 ERP 시스템을 "납세자가 공인 서비스 제공자와 맺은 약정에 따라 유지할 수 있다"고 말하며, 패키지 시스템이라면 그 약정을 이행하는 것은 벤더의 몫입니다. 귀사가 할 일은 마스터 데이터와 테스트입니다.

귀사가 직접 서비스 제공자가 될 수도 있습니다. 인가 기준에는 IT 업종이 포함된 오만 상업 등록, 최소 납입 자본금, 운영 이력, ISO/IEC 27001 인증이 들어 있고, FAQ는 Peppol eDelivery와 PINT OM 테스트 스위트 통과를 덧붙입니다. 소프트웨어 회사에는 맞는 길입니다. 소매업체에게 지름길은 아닙니다.

이 글은 그 밖의 모든 회사를 위한 것입니다. 인보이스가 자체 ERP, 사내 POS 시스템, 오래된 데이터베이스에 덧붙인 과금 엔진, 또는 아직 인보이스를 손으로 쓰는 지점에서 나오는 회사입니다.

소프트웨어에서 바뀌어야 할 것

인보이스 데이터를 PINT Oman에 매핑하기

매핑에 관한 FAQ의 안내는 한 줄입니다. 오만 PINT 사양을 쓰라는 것입니다. 의미 모델에서 노력이 가장 많이 들어가는 곳은 오만 고유 필드(BTOM 접두사)입니다.

  • 모든 문서의 UUID(BTOM-002). RFC 4122 버전 5, 즉 이름 기반 UUID여야 합니다. 법인, 지점, POS, 문서 번호처럼 안정적인 값에서 도출하면 재전송해도 두 번째 인보이스가 아니라 같은 UUID가 나옵니다.
  • 인보이스 거래 유형(BTOM-001). 각 자리가 플래그인 20자리 문자열입니다. 전체 세금 인보이스, 간이 세금 인보이스, 역발행, 제3자 발행, 수출, 간주공급, 용역 수입 역과세, 이윤 마진, 전자상거래, 재화 수입, 특별 구역 공급, 선수금 등이 있습니다. 플래그는 여러 개를 설정할 수 있습니다. 시스템은 인보이스마다 어떤 플래그가 해당하는지 알아야 하는데, 대부분의 ERP는 이 정보를 저장한 적이 없습니다.
  • 판매자와 구매자 식별자와 그 체계 코드. 상업 등록, 세금 식별 번호, 신분증 번호, 여권, 수입자 세관 ID, 특별 구역 허가 번호입니다.
  • 통화. 인보이스 통화, VAT 회계 통화, 둘 사이의 환율, 회계 통화 기준 VAT 합계에 각각 필드가 있습니다.
  • VAT 면세, 영세율 사유, 서비스 유형, 국가 하위 행정구역의 코드 목록.

인보이스 라인은 깔끔하게 매핑되고 마스터 데이터는 그렇지 않을 것이라고 예상하십시오. VATIN이 없는 고객 레코드, 빠진 CR 번호, 자유 텍스트로 된 면세 사유, 지역 코드가 없는 주소는 모두 첫 실제 인보이스 전에 정리해야 합니다.

모든 판매를 하나의 문서로

POS 시스템을 바꾸는 규칙은 이것입니다. "B2C 거래에는 합산 인보이스가 허용되지 않습니다. 전자 인보이스는 인보이스마다 따로 발행해야 합니다." 일일 합계는 없습니다. 하루에 3,000건을 판매하는 매장은 하루에 전자 인보이스 3,000건을 보냅니다.

FAQ는 B2C 제출에 24시간, B2B 제출에 실시간을 줍니다. POS로서는 다음을 뜻합니다.

  • POS가 판매 시점에 UUID와 함께 XML을 만듭니다(또는 판매 건을 그 일을 하는 서비스로 넘깁니다). B2C에는 별도의 영수증 UUID 필드(BTOM-004)가 있습니다.
  • 저장 후 전달(store-and-forward) 대기열이 네트워크나 서비스 제공자가 멈췄을 때 문서를 보관했다가 24시간 안에 내보냅니다.
  • 전송되지 않은 문서가 있으면 스물세 시간이 지나서가 아니라 몇 시간 안에 누군가에게 알림이 갑니다.

계약하기 전에 서비스 제공자의 가격을 귀사의 물량과 맞춰 보십시오. FAQ는 서비스 제공자마다 자체 모델을 정하며, 여기에는 "구독료, 거래당 수수료 또는 그 밖의 가격 방식이 포함될 수 있다"고 말합니다. 소매 물량에서 문서당 수수료는 예산의 한 항목이 됩니다.

실시간 B2B

사업자 대상 인보이스는 실시간으로 제출합니다. ERP가 인보이스를 전기하면 서비스 제공자가 검증하고 결과가 돌아옵니다. 이는 인보이스 워크플로를 두 가지로 바꿉니다. 검증 오류가 이제 전기 시점에 드러나므로, 재무팀의 누군가에게는 거부 내용을 보여 주고 고칠 수 있게 해 주는 화면이 필요합니다. 그리고 인보이스 번호, UUID, 재시도 로직이 첫날부터 정확해야 합니다. 타임아웃 뒤에 무작정 다시 보내는 것이 중복 인보이스가 생기는 경로이기 때문입니다.

흐름은 반대 방향으로도 흐릅니다. 귀사가 구매자일 때, 이미 Fawtara에 들어온 회사의 공급자 전자 인보이스가 서비스 제공자를 통해 XML로 도착하며, 매입채무 쪽에 이를 받아들일 방법이 필요합니다.

인쇄 영수증의 QR 코드

QR 코드는 서비스 제공자가 아니라 귀사(코너 1)가 생성합니다. 전체 인보이스든 간이 인보이스든 모든 B2C 거래에 필수이며, XML이 아니라 사람이 읽는 인보이스에 표시됩니다. OTA는 모바일 앱으로 인보이스를 검증하는 데 이를 쓸 계획입니다. QR의 내용에 대해 FAQ는 Peppol Oman Architecture 문서(버전 1.0.2)의 부록 D를 가리킵니다. 누군가 영수증을 다시 디자인하기 전에 그 부록부터 확보하십시오. 영수증 템플릿과 프린터 드라이버도 이 프로젝트에 포함됩니다.

크레딧 노트, 반품, 정정

발행된 전자 인보이스는 전자 크레딧 노트나 데빗 노트를 발행해 조정합니다. 사양에는 원 인보이스의 UUID와 사유 코드를 위한 필드(BTOM-031과 BTOM-032)가 있으므로, 매장 계산대에서의 환불은 원래 판매를 찾을 수 있어야 합니다.

수입과 역발행

재화와 용역의 수입은 역발행 인보이스로 보고합니다. 구매 흐름에서 아무 문서도 만들지 않고 수입을 장부에 올리고 있다면, 그곳에 새 단계가 생깁니다.

보관

보관은 귀사의 몫으로 남습니다. FAQ는 OTA가 인보이스 정보를 납세자에게 돌려주지 않으며 Peppol은 문서를 저장하지 않는다고 말합니다. 검증된 XML, 서비스 제공자의 응답, 인쇄본을 VAT 법령의 보관 규정에 따라 함께 보관하십시오.

기한에서 거꾸로 짠 계획

FAQ에 따르면 OTA는 시행 참여자에게 온보딩 최소 6개월 전에 연락합니다. 4월 그룹이라면 바로 지금입니다.

2027년 4월 1일에 시작한다면:

  1. 2026년 10월: 시행 시기 확인 도구와 FAQ 기준으로 귀사의 그룹을 확인합니다. 인보이스를 발행하는 모든 시스템을 나열합니다. ERP, 각 POS, 전자상거래 결제, 임대나 구독 과금, 그리고 수기 인보이스 장부까지입니다.
  2. 2026년 11월: 서비스 제공자를 고릅니다. 계약 전에 API 문서와 샌드박스를 요청하고, B2C 물량, 문서당 가격, 오프라인 처리, 검증 응답의 형태를 물어보십시오. Fawtara 포털에서 연결을 요청합니다.
  3. 2026년 12월부터 2027년 1월까지: 구축합니다. 필드 매핑, UUID 생성, 거래 유형 로직, POS 대기열, QR 코드, 크레딧 노트 흐름, 수신 인보이스입니다. PINT Oman 다운로드에 있는 오만 schematron 규칙을 자체 테스트 파이프라인에서 돌려, 실패가 서비스 제공자 쪽이 아니라 개발 단계에서 드러나게 하십시오.
  4. 2027년 2월: 실제로 발행하는 모든 거래 유형의 실제 샘플로, 까다로운 것(수출, 영수증 없는 반품, 외화)까지 포함해 서비스 제공자 샌드박스와 종단 간 테스트를 합니다.
  5. 2027년 3월: 지점이나 사업부 하나로 운영 리허설을 하고, 전환 계획과 첫 몇 주의 지원 당번표를 마련합니다.

2027년 10월 1일에 시작한다면 순서는 같고 6개월씩 뒤로 밀립니다. 1분기 말까지 서비스 제공자를 고르고, 2분기에 구축하고, 8월까지 테스트를 끝냅니다. 여유 시간을 써 버리지 마십시오. 데이터 정리는 언제나 누구의 예상보다 오래 걸립니다.

아직 불확실한 것

날짜는 한 번 바뀌었고 다시 바뀔 수 있습니다. 2026년 8월 31일 자 PDF를 기준으로 계획하고, 뉴스 보도에 기대지 말고 매달 OTA 문서를 확인하십시오. 법적 근거는 VAT법 시행령을 개정하는 결정 189/2026입니다. FAQ는 의무가 시작되면 VAT 법령에 따라 과태료가 적용된다고 하지만 금액은 밝히지 않으므로 저희도 적지 않습니다.

사양에도 버전이 있습니다. Peppol 사이트의 현행 PINT Oman 패키지에는 2026년 7월 29일의 릴리스 날짜가 붙어 있습니다. 개발 기준 버전을 고정하고 릴리스 노트를 지켜보십시오.

도움이 필요하시면

저희는 귀사가 실제로 운영하는 시스템과 의무가 요구하는 형식 사이의 커넥터를 구축합니다. 필드 매핑, UUID와 번호 체계 로직, POS 대기열, 파이프라인 안의 검증, 귀사가 선택한 서비스 제공자와의 연동입니다. 이 작업은 전자 인보이스 연동 서비스가 다루며, ERP 자체가 걸림돌이라면 ERP 현대화에서 시작합니다.

4월 그룹에 속하는데 아직 서비스 제공자를 고르지 않았다면 office@c9group.dev로 연락 주십시오.