SAP FI 전표일·전기일·입력일, 어떤 날짜를 봐야 할까

“9월에 입력한 전표인데 왜 8월 실적에 잡힐까?” SAP FI에서 이런 질문을 받으면 전표의 날짜 필드를 나란히 보는 것이 좋습니다. 전표일은 원증빙의 날짜, 전기일은 회계기간을 결정하는 기준, 입력일은 회계전표가 시스템에 입력된 날짜입니다. 서로 다른 날짜가 기록되어 있다는 사실만으로 오류라고 판단할 수는 없습니다.

이 글은 SAP S/4HANA 2025 FPS01의 일반 FI 회계전표를 기준으로 설명합니다. 화면의 한글 명칭과 조회 항목은 사용하는 앱·언어·권한에 따라 달라질 수 있으므로 영문 이름도 함께 확인해보세요. 임시저장 전표나 이관 데이터 등 별도 절차의 날짜 처리까지 같은 방식이라고 가정하지는 않습니다.

세 날짜가 각각 답하는 질문

전표일(Document Date)은 원래 증빙이 발행된 날짜입니다. 송장에 적힌 날짜와 시스템에 기록한 증빙 날짜를 대조하려면 이 필드가 출발점입니다. 원증빙은 먼저 발행되고 전표 입력은 며칠 뒤에 이루어질 수 있으므로 전표일과 입력일이 반드시 같아야 하는 것은 아닙니다. 둘의 차이가 있다면 우선 어떤 사실을 기록한 날짜인지 확인합니다.

전기일(Posting Date)은 회계상 어느 기간에 반영했는지 확인하는 기준입니다. 시스템은 입력한 전기일과 회계연도 설정에 따라 원장별 전기기간을 결정합니다. 해당 기간에 전기하려면 필요한 전기기간이 열려 있어야 합니다. 회계연도 구성이 회사마다 같다는 보장은 없으므로 전기일의 달 숫자를 곧바로 회계기간 번호로 읽지 않는 것이 좋습니다.

입력일(Entry Date)은 회계전표가 입력된 날짜입니다. 시스템에 어느 날 입력되었는지 추적할 때 쓰는 값으로, 증빙 발행일이나 회계 귀속 기간을 대신하지 않습니다. 증빙이 실제로 회사에 도착한 날을 알고 싶다면 수신 기록을, 마지막으로 바뀐 내용을 알고 싶다면 변경 이력을 확인해야 합니다. 입력일 하나로 이 사실들을 모두 설명할 수는 없습니다.

기술 필드를 함께 적어두면 화면의 번역이나 열 이름이 달라도 대조하기 쉽습니다. 전표 헤더 BKPF에서 BLDAT는 전표일, BUDAT는 전기일, CPUDT는 입력일입니다. 운영 문의에 이 영문 이름이나 필드명을 남기면 서로 다른 날짜를 보고 대화하는 일을 줄일 수 있습니다.

8월 증빙을 9월에 입력한 가상 사례

다음은 실제 회사 자료가 아닌 설명용 예시입니다. 회계연도가 달력연도와 같고 일반 전기기간을 사용하는 회사에서 2026년 8월 29일자로 증빙이 발행되었다고 하겠습니다. 회계 담당자는 해당 건을 8월에 반영하기로 판단했고, 전기일을 8월 31일로 정했습니다. 전표를 입력하는 시점에 필요한 8월 전기기간은 열려 있다고 가정합니다.

실제로 시스템에 회계전표를 입력한 날은 9월 3일입니다. 그러면 한 전표에 전표일 2026-08-29, 전기일 2026-08-31, 입력일 2026-09-03이 함께 기록될 수 있습니다. 세 날짜는 증빙 발행, 회계 반영, 시스템 입력이라는 서로 다른 사실을 기록합니다.

이 예시에서 8월 반영은 날짜의 역할을 설명하기 위해 미리 정한 조건입니다. 8월 증빙이면 언제나 8월에 전기해야 한다거나, 9월에 입력했다는 이유로 전기일을 임의로 바꾸어도 된다는 뜻은 아닙니다. 실제 회계 귀속은 증빙과 회사의 회계처리 기준에 따라 판단해야 합니다. 운영 담당자는 그 판단과 시스템에 기록된 값이 일치하는지를 구분해 확인할 수 있습니다.

같은 전표를 8월과 9월에 각각 찾을 수 있는 이유

‘8월 전기분’을 찾는다면 날짜 조건은 전기일 2026-08-01부터 2026-08-31까지입니다. 예시 전표의 전기일은 8월 31일이므로 이 조건에 포함됩니다. ‘9월 입력분’을 찾는다면 입력일 2026-09-01부터 2026-09-30까지를 조건으로 삼습니다. 입력일이 9월 3일이므로 이 조회에도 포함됩니다. 다른 조건이 같고 해당 필터를 지원하는 조회라는 전제입니다.

반대로 전기일을 9월로만 제한하면 이 전표는 해당 날짜 조건에 포함되지 않습니다. 입력일을 8월로만 제한한 경우도 마찬가지입니다. 전표가 사라진 것이 아니라 질문이 달라진 것입니다. ‘9월에 입력된 건’과 ‘9월로 전기한 건’은 이름이 비슷해 보여도 같은 집합이 아니므로, 두 목록의 건수가 다르다는 사실만으로 누락을 확정할 수 없습니다.

여러 필터를 함께 걸었다면 각 조건도 나란히 확인해야 합니다. 예를 들어 전기일은 8월로, 입력일은 9월로 제한하고 두 조건을 모두 만족하는 건을 찾는 조회라면 예시 전표가 대상이 됩니다. 반면 전기일과 입력일을 모두 9월로 걸면 예시 전표는 빠집니다. 실제 화면에서 조건이 어떻게 결합되는지는 해당 앱이나 보고서의 동작을 확인해야 합니다.

월별 회계 보고서를 비교한다면 날짜 외에 선택한 원장과 회계연도·전기기간도 맞춰야 합니다. 단순 전표 목록과 회계 보고서는 목적과 필터가 다를 수 있습니다. ‘같은 달’이라는 표현보다 실제로 어떤 전표를 포함하는 조건인지 적어보면 차이를 좁히기 쉽습니다.

운영 문의를 다시 확인하기 쉬운 문장으로 쓰기

“9월 전표가 누락됐습니다”만으로는 원증빙이 9월인지, 전기일이 9월인지, 입력일이 9월인지 알기 어렵습니다. 먼저 확인하려는 목적을 정리합니다. 원증빙 대조인지, 월별 회계 반영 확인인지, 특정 날짜에 입력한 작업 추적인지가 명확해지면 어느 날짜 필드를 기준으로 볼지도 정하기 쉬워집니다.

예를 들어 “입력일 2026-09-01~2026-09-30 조건에서는 조회되지만, 전기일 2026-09-01~2026-09-30 조건에서는 조회되지 않습니다. 전표의 전기일은 2026-08-31이며 두 조회의 나머지 조건은 같습니다”라고 적을 수 있습니다. 여기에 사용하는 앱이나 보고서 이름, 회사코드·회계연도·전표번호를 덧붙이면 같은 건을 다시 찾기 쉽습니다.

화면을 비교할 때는 표시된 날짜 열의 이름과 조회 조건에 사용한 날짜 필드를 모두 남기는 편이 좋습니다. 목록에 보이는 날짜가 선택 조건에 사용한 날짜와 같다고 미리 단정하지 말고 각각 확인합니다. 계정·전표 상태 등 다른 필터와 조회 권한도 결과에 영향을 줄 수 있으므로, 조건을 맞춘 뒤에도 차이가 남으면 함께 살펴볼 항목으로 기록합니다.

날짜가 다르면 먼저 맞춰야 한다는 오해

세 날짜를 같은 값으로 만드는 것이 정상 처리의 목표는 아닙니다. 발행일, 회계 반영 기준, 입력 기록이 다르면 날짜가 다른 것이 자연스러울 수 있습니다. 먼저 값을 바꾸기보다 원증빙과 전표 헤더를 대조하고, 회계 담당자의 반영 판단과 조회 조건을 확인하는 순서가 도움이 됩니다. 기간이 닫혀 있다는 사정만으로 날짜를 바꾸면 원래 확인하려던 사실까지 달라질 수 있습니다.

확인 결과를 남길 때도 ‘정상’이라는 한 단어보다 근거가 있는 문장이 유용합니다. “전기일이 8월 31일이므로 9월 전기일 조건에서는 제외되고, 입력일이 9월 3일이므로 9월 입력일 조건에는 포함됩니다”처럼 설명하면 됩니다. 날짜의 역할과 실제 필터를 함께 적어두면 정상적인 기간 차이와 추가 확인이 필요한 입력 오류를 나누어 볼 수 있습니다.