세금계산서 발행, ERP와 국세청 절차를 연결하는 순서

합계만 저장하면 1원이 어긋납니다

부가가치세법 제30조의 세율은 10%입니다. 공급가액 12,000,000원이면 세액 1,200,000원, 합계 13,200,000원으로 깔끔하게 나눠집니다. 문제는 금액이 깔끔하지 않을 때입니다.

단가 3,333원에 3개를 판 거래의 공급가액은 9,999원이고 세액은 999.9원입니다. 원 단위로 올리면 1,000원, 내리면 999원입니다. 합계가 10,999원과 10,998원으로 갈립니다.

ERP가 합계만 저장하고 세액을 역산하는 구조라면 이 1원이 매 거래마다 생깁니다. 거래가 쌓이면 월 마감에서 맞지 않는 금액이 됩니다. 해결은 계산식이 아니라 저장 구조에 있습니다.

세 칸을 각각 저장합니다

공급가액, 세액, 합계를 모두 저장하는 것이 기본입니다. 세 칸 가운데 두 개만 저장하고 하나를 계산하면, 계산하는 쪽의 반올림 기준이 발급 시스템과 달라질 수 있습니다.

저장할 때는 어느 칸이 원본인지도 정해야 합니다. 공급가액에서 세액을 구하는 거래와 합계에서 역산하는 거래가 섞이면 같은 품목이 다른 금액으로 기록됩니다. 소비자 가격을 합계 기준으로 표기하는 업종에서 특히 자주 생깁니다.

실무에서는 거래 유형별로 원본 칸을 고정하는 방식이 안전합니다. 기업 간 거래는 공급가액을 원본으로, 소비자 거래는 합계를 원본으로 두고, 나머지 두 칸은 그 원본에서 한 번만 계산해 저장합니다.

• 세 칸을 모두 저장합니다.
• 거래 유형별로 원본 칸을 고정합니다.
• 계산은 한 번만 하고 결과를 저장합니다.

시점이 네 개입니다

세금계산서에는 날짜가 하나가 아닙니다. 작성일자, 발급일, 전송일, 그리고 신고가 귀속되는 과세기간이 각각 다를 수 있습니다.

작성일자는 거래가 일어난 날이고 발급일은 서류가 만들어진 날입니다. 전송일은 발급한 서류가 국세청에 전달된 날입니다. 이 셋이 같은 날인 거래가 대부분이지만, 월말 거래에서 어긋나면 귀속 과세기간이 달라질 수 있습니다.

ERP에서 이 네 개를 한 칸으로 합치면 나중에 분리할 수 없습니다. 발급·전송 기한의 구체적인 날짜 규정은 이 글에서 확인하지 않았으므로 적지 않지만, 날짜 칸을 네 개로 나눠 두는 설계는 규정과 무관하게 필요합니다. 규정을 확인한 뒤에도 칸이 하나면 적용할 자리가 없습니다.

ERP에서 발급까지 이어지는 다섯 단계

흐름을 단계로 끊어 두면 어디서 멈췄는지 알 수 있습니다. 거래 확정, 공급가액과 세액 산출, 서류 발급, 국세청 전송, 전송 결과 확인입니다.

실무에서 가장 자주 멈추는 자리는 네 번째와 다섯 번째 사이입니다. 전송은 했지만 결과를 확인하지 않아, 실패한 건이 그대로 남습니다. ERP에 전송 상태 칸이 없으면 이 실패가 월 마감 때까지 드러나지 않습니다.

상태 값은 최소 네 개가 필요합니다. 미발급, 발급완료, 전송완료, 전송실패입니다. 발급완료와 전송완료를 하나로 묶으면 전송실패를 구분할 자리가 사라집니다.

수정과 취소를 어떻게 담을까

발급한 세금계산서를 고치는 일은 새 서류를 만드는 일입니다. 원본을 덮어쓰면 이력이 사라지고, 어떤 금액으로 신고했는지 추적되지 않습니다.

그래서 수정은 원본을 남기고 수정분을 별도 건으로 저장하는 구조가 필요합니다. 두 건이 연결되어야 하므로 원본 참조 칸이 있어야 합니다. 합계 13,200,000원이 12,100,000원으로 수정되었다면, 두 금액이 모두 남고 차액 1,100,000원이 어느 과세기간에 반영되는지가 기록되어야 합니다.

결론을 바꾸는 예외는 발급 전 취소입니다. 아직 전송되지 않은 건은 수정분을 만들 필요 없이 원본을 고칠 수 있습니다. 그래서 수정 처리 로직은 전송 상태를 먼저 읽어야 하고, 이것이 앞 단계에서 상태 칸을 네 개로 나눠 둬야 하는 또 하나의 이유입니다.