FIELD NOTES

TRADE DOCUMENT AUTOMATION

견적서 자동 생성 — 환율과 조건을 값에서 분리하기

견적서에 환율이 숫자로만 박혀 있으면 며칠 뒤에 그 견적이 무엇을 근거로 했는지 알 수 없게 됩니다. 조건을 값에서 떼어냈습니다.

11 min
견적서에서 선적 서류까지 콘셉트 이미지
원본 전체 보기 ↗

며칠 뒤에 오는 질문

기존 견적서에는 원화 환산 금액이 숫자로만 들어 있었습니다.

며칠 뒤 바이어가 묻습니다. "이 금액 맞습니까?"

어느 시점 환율로 계산한 건지 확인할 방법이 없었습니다. 그래서 다시 계산합니다. 다시 계산하면 값이 달라집니다. 달라진 이유를 설명하는 메일을 또 씁니다.

숫자 하나 때문에 메일이 세 통 오갑니다.

견적을 세 층으로 나눴다

기준 통화 금액

공급 단가 기준

적용 조건

환율 · 기준일 · 조건

표시 금액

계산 결과

표시 금액은 저장하지 않고 매번 계산한다
  • 기준 통화 금액 — 실제 근거입니다. 이것만 저장합니다.
  • 적용 조건 — 환율, 기준일, 인코텀즈, 유효기간, 결제 조건.
  • 표시 금액 — 위 둘로 계산되어 나오는 값. 저장하지 않습니다.

대신 어떤 조건으로 계산했는지를 견적서에 함께 인쇄합니다.

Currency Basis   USD
Exchange Rate    1,382.50 KRW/USD
Rate Date        2026-04-30
Validity         14 days from issue date
Incoterms        FOB Busan
Payment          T/T 30 days after B/L date

이 블록이 들어가자 환율 관련 문의가 거의 사라졌습니다. 물어볼 것이 문서 안에 이미 답으로 있으니까요.

유효기간을 강제로 넣게 했다

전에는 유효기간이 빈 견적서가 나가곤 했습니다. 그러면 반년 뒤에 그 견적서를 들고 오는 바이어가 생깁니다. 그때 가격은 이미 다릅니다.

유효기간 없이는 견적서를 만들 수 없게 막았습니다. 기본값은 14일로 두되 조정할 수 있게 했습니다.

막을 것은 막고, 대신 기본값을 준다. 자유롭게 두면 빠지고, 완전히 고정하면 현실을 못 담습니다.

이 원칙은 현장 데이터 연재의 "기본값을 현장 기준으로 잡는다"와 같은 이야기입니다. 도메인이 달라도 사람이 양식을 대하는 방식은 같았습니다.

견적 번호에 의미를 넣지 않았다

처음에는 견적 번호에 정보를 담으려 했습니다.

Q-2026-ABC-0042
  └연도 └바이어코드 └순번

보기에 좋고 번호만 봐도 알 수 있습니다. 안 했습니다.

번호에 의미를 넣으면 바이어 코드가 바뀌거나 조직이 개편될 때 번호 체계가 무너집니다. 그리고 반드시 바뀝니다.

Q-2026-0042        번호는 순번만
  buyer_id         별도 필드
  issued_at        별도 필드
  region           별도 필드

식별자에 정보를 넣으면 나중에 반드시 후회합니다. 이건 이전 시스템에서 이미 겪었던 일이라 이번에는 처음부터 피했습니다.

반올림 규칙을 문서에 적었다

통화가 섞이면 반올림에서 값이 갈립니다. 우리가 계산한 총액과 바이어가 계산한 총액이 몇 센트 차이 나는 일이 종종 있었습니다.

단가 × 수량을 먼저 반올림한 뒤 합산   →  USD 6,200.05
합산한 뒤 마지막에 반올림              →  USD 6,200.00

몇 센트지만 은행 서류에서는 문제가 됩니다. 그래서 규칙을 정하고 견적서 하단에 명시했습니다.

Rounding   Line total rounded to 2 decimals; grand total = sum of line totals

계산 방식을 문서에 적어두면, 값이 다를 때 어느 쪽이 틀렸는지 30초 만에 확인됩니다. 적어두지 않으면 메일이 다섯 통 오갑니다.

결과

견적서 생성

건당 작성 시간

40분8분

환율 관련 문의

월 5~6건거의 없음

8분의 대부분은 품목을 고르고 수량과 조건을 정하는 시간입니다. 즉 실제로 판단하는 시간만 남았습니다.

다음 편에서 할 것

견적이 확정되면 선적 서류를 만들어야 합니다. PI, CI, PL 세 장입니다.

이 셋은 서로 다른 문서처럼 보이지만 사실 같은 데이터를 다른 각도로 본 것입니다. 그런데 각각 따로 만들고 있었으니 어긋날 수밖에 없었습니다.

리도 프로필

리도 인사이트

기술을 현장 언어로 다시 풀어 쓰는 사람

3D 설계, 광통신 인프라 장비 개발, 글로벌 현장 교육을 19년 넘게 다뤄왔고, 요즘은 AI 자동화, 꿈꾸는 카메라, 실무 채널 운영을 연결해 복잡한 일을 더 쉽게 만드는 방법을 기록하고 있습니다.

다음 대화

읽고 끝내지 말고, 실제 문제로 이어가도 좋습니다.

자동화, 설계, 교육, 콘텐츠 중 무엇이든 지금 필요한 문제부터 같이 정리해볼 수 있습니다.

편하게 문의하기