49,000원이 48,999원으로: 부가세 역산에서 1원이 어긋나는 이유

가격표에는 49,000원이었던 광고 상품이 계약서에는 48,999원으로 찍혔습니다. RankBoard 파트너 포털에서 실제로 있었던 일입니다. 부가세 포함 금액을 공급가액과 부가세로 나눌 때 1원이 어긋나는 일은 대개 반올림 방식이 서로 달라서 생깁니다. 원인과 고친 방법을 적고, 전표를 자동으로 넣을 때 금액을 맞추는 원칙을 뒤에 정리했습니다.

파트너 포털 계약서에 찍힌 48,999원

RankBoard에는 제휴 매장과 광고주가 쓰는 파트너 포털이 있습니다. 광고주는 포털에서 광고 상품을 고르고 전자계약에 서명한 뒤 입금합니다. 가격표에서 부가세 포함 49,000원이던 상품이 계약서 합계에서는 1원 모자랐습니다.

원인은 부가세를 거꾸로 계산하는 부분에 있었습니다. 합계에서 공급가액과 부가세를 나누는 계산에 프로그래밍 언어의 기본 반올림을 썼고, 이 반올림은 0.5를 무조건 올리지 않고 짝수 쪽으로 보냅니다. 학교에서 배운 반올림과 다릅니다.

1원은 어떻게 사라지나요?

아래는 같은 종류의 오차가 생기는 계산 예시입니다.

0.5를 올렸다면 부가세는 4,455원이고 합계는 49,000원입니다. 한 단계의 반올림 방식 차이가 고객이 본 금액과 계약서 금액을 다르게 만듭니다. 소수를 다루는 방식 때문에 4,454.5가 컴퓨터 안에서 4,454.4999…로 저장되는 경우에도 같은 일이 생깁니다.

어떻게 고쳤나요?

금액은 정확한 십진 계산으로 합니다. 소수를 근삿값으로 저장하는 방식을 쓰지 않고, 원 단위까지 정확하게 계산하는 십진수 방식을 씁니다. 반올림도 0.5를 올리는 방식으로 명시합니다.

가격표는 서버 한 곳에서만 관리합니다. 화면, 계약서, 영수증 메일이 각자 금액을 계산하면 어딘가에서 또 어긋납니다. 금액 계산은 서버의 한 곳에서만 하고, 나머지는 그 결과를 그대로 받아 씁니다.

그 뒤로 광고주가 화면에서 본 금액과 계약서 금액은 항상 같습니다.

TIP자동화 결과를 검산할 때 끝자리가 5로 끝나는 금액을 일부러 넣어 보세요. 1원 차이는 대부분 이런 경계값에서 드러납니다.

전표 자동 입력에서 어긋나는 곳

판매 전표에는 공급가액과 부가세를 나눠 넣습니다. 발주서에는 부가세 포함 합계만 적혀 있는 경우가 많아서, 자동화가 합계를 공급가액과 부가세로 나눠야 합니다. 이때 생길 수 있는 어긋남은 이렇습니다.

줄마다 반올림하고 합칠지, 합친 뒤 한 번 반올림할지도 회사마다 정해 둔 방식이 있습니다. 거래처가 보내는 세금계산서와 맞추려면 이 방식부터 확인해야 합니다.

만들 때 무엇을 정하나요?

루코 웍스는 발주서 → ERP 전표 같은 금액을 다루는 자동화를 만들 때 진단 단계에서 다음을 묻고 문서로 남깁니다.

• 발주서 금액이 부가세 포함인지, 별도인지
• 공급가액과 부가세 중 무엇을 먼저 계산하는지
• 원 단위 처리를 올림, 버림, 반올림 중 무엇으로 하는지
• 줄 단위로 맞추는지, 전표 합계로 맞추는지

그리고 금액 계산은 한 곳에서만 하게 만들고, 담당자가 승인 화면에서 본 금액이 그대로 전표에 들어가게 합니다. 끝자리 5로 끝나는 금액과 줄이 많은 발주서로 검산한 결과도 함께 드립니다.

정리하면

1원 차이는 대개 반올림 규칙을 정하지 않아서 생깁니다. 금액을 다루는 자동화를 맡길 때는 "부가세는 어떤 방식으로 나누나요?"를 물어보세요. 바로 답이 나온다면 그 부분을 생각해 둔 것입니다.