ERP의 계정과목이나 부서·프로젝트 코드가 바뀌었다고 승인된 지출결의서를 모두 다시 작성할 필요는 없습니다. 카드 거래 원본, 결의·승인 기록, 회계 코드 매핑, ERP 반영 결과를 분리하고 변경 시점에 맞는 재처리 규칙을 정하면 됩니다.
핵심은 연동 방식이 아니라 통제입니다. 파일 업로드든 시스템 간 인터페이스든, 변경 전후 값과 승인 근거를 남기고 건수·금액을 대사하며 같은 거래가 두 번 반영되지 않게 해야 재작업을 줄일 수 있습니다.
“확인 기준일: 2026년 7월 14일 이 글은 특정 ERP의 지원 기능을 전제로 하지 않습니다. 실제 처리 방식은 회사의 회계정책, 마감 규칙, 권한 구조, ERP 사양과 내부회계관리제도 적용 범위에 맞춰 정해 주세요.”*읽기 전 참고사항
먼저 답: 어떤 자료를 분리해야 하나요?
ERP 코드 변경에 흔들리지 않으려면 한 장의 지출결의서를 계속 덮어쓰기보다 다음 여섯 층을 구분해야 합니다.
| 구분 | 고정하거나 기록할 값 | 변경할 때 지킬 원칙 |
|---|---|---|
| 카드 거래 원본 | 승인번호, 카드 식별키, 거래일시, 금액, 가맹점, 취소 연결키 | 원본값을 수정하지 않고 정정·취소 기록을 별도로 연결 |
| 증빙·사용 목적 | 영수증, 참석자·거래처, 업무 목적, 예산 근거 | 보완 이력과 제출자를 기록 |
| 지출결의 | 결의번호, 작성자, 작성 시점, 항목별 금액 | 수정본을 새 버전으로 생성 |
| 승인 | 승인자, 승인 시각, 승인 당시 금액·코드 | 승인 뒤 핵심 값이 바뀌면 재승인 또는 정정 승인 |
| 회계 매핑 | 계정과목, 거래처, 부서, 프로젝트, 세무 구분, 적용 기간 | 코드의 유효 시작일·종료일과 매핑 버전을 함께 보존 |
| ERP 반영 | 전송 ID, 전표번호, 반영 상태, 오류 코드, 반영 시각 | 성공·실패·보류를 구분하고 재전송 전 기존 결과 확인 |
이 구조에서는 코드가 바뀌어도 카드 거래와 증빙을 다시 만들지 않습니다. 변경의 영향을 받는 매핑과 전표 반영 단계만 새 버전으로 처리할 수 있습니다.
ERP 코드 변경이 왜 지출결의서 재작성으로 이어지나요?
재작업은 대개 카드 내역을 불러오는 방식보다 한 문서에 서로 다른 상태를 섞어 두는 구조에서 생깁니다. 카드 거래는 그대로인데 결의서의 계정과목이 바뀌었거나, 결의는 승인됐지만 ERP 전표는 아직 생성되지 않았을 수 있습니다. 이미 전표가 반영된 뒤 프로젝트 코드가 폐기되는 경우도 있습니다.
이 상태를 하나의 최종값으로만 관리하면 다음 문제가 생깁니다.
- 승인 당시 값과 현재 값 중 무엇이 맞는지 알기 어렵습니다.
- 코드표를 수정한 뒤 과거 결의서까지 조용히 달라질 수 있습니다.
- 재전송이 신규 전표인지 기존 전표의 대체인지 구분되지 않습니다.
- 일부 행만 실패했는데 전체 파일을 다시 올려 중복 전표가 생길 수 있습니다.
- 결산 뒤 수정한 전표가 어느 보고서에 반영됐는지 추적하기 어렵습니다.
따라서 결의 승인 상태와 ERP 반영 상태를 별도 축으로 두고, 변경 시점별 조치를 정해야 합니다.
변경 시점에 따라 무엇을 다시 처리해야 하나요?
같은 코드 변경이라도 승인과 전표 반영 시점에 따라 처리 범위가 다릅니다. 아래 표는 회사 규정을 만들 때 사용할 수 있는 운영 기준입니다.
| 변경 시점 | 확인할 질문 | 권장 처리 | 피할 처리 |
|---|---|---|---|
| 승인 전 | 새 코드가 거래일 기준으로 유효한가? | 결의 초안의 매핑을 바꾸고 일반 승인 진행 | 과거 코드와 새 코드를 근거 없이 혼용 |
| 승인 후·ERP 반영 전 | 변경이 승인 내용과 예산 책임에 영향을 주는가? | 수정본을 만들고 영향에 따라 재승인 또는 정정 승인 | 승인 완료본을 기록 없이 덮어쓰기 |
| ERP 반영 후·마감 전 | 기존 전표를 수정할 수 있는가, 대체 전표가 필요한가? | 기존 전표번호를 연결해 수정 또는 취소·대체 처리 | 같은 거래를 신규 전표로 다시 전송 |
| 마감 후 | 기간 재개방이 가능한가, 다음 기간 정정이 필요한가? | 회사의 마감·정정 정책과 승인에 따라 처리하고 보고 영향 기록 | 마감 전표를 담당자 판단만으로 변경 |
| 코드 폐기·통합 | 과거 거래를 소급 변경할 근거가 있는가? | 새 거래의 적용일부터 새 코드를 쓰고 과거 자료는 원래 코드와 매핑 이력 보존 | 코드표 정리만으로 과거 거래를 일괄 치환 |
| 조직개편·프로젝트 이관 | 거래 발생일과 책임 귀속일이 같은가? | 유효일과 비용 귀속 기준을 분리해 승인 | 현재 조직도만 보고 과거 비용을 재분류 |
이 표의 재승인과 정정 승인은 법정 공통 용어가 아니라 회사가 정해야 할 통제 절차입니다. 금액, 예산 책임, 세무 구분, 외부 보고에 영향을 주는 변경일수록 승인 수준을 높이고, 단순 설명 보완은 낮은 단계에서 처리하도록 구분해 주세요.
계정과목·부서·프로젝트 코드는 어떻게 관리해야 하나요?
코드의 이름만 보관하면 과거 거래를 재현하기 어렵습니다. 최소한 코드 ID, 표시명, 상태, 유효기간, 상위 코드, 대체 코드, 변경 사유, 승인자를 함께 관리해야 합니다.
| 필드 | 예시 | 통제 목적 |
|---|---|---|
| 코드 ID | PRJ-042 | 이름이 바뀌어도 같은 대상을 식별 |
| 표시명 | 신제품 출시 프로젝트 | 실무자가 이해할 명칭 제공 |
| 유효 시작일·종료일 | 2026-03-01~2026-12-31 | 거래일 기준 사용 가능 여부 판단 |
| 상태 | 사용, 사용중지, 통합 | 신규 사용과 과거 조회를 구분 |
| 대체 코드 | PRJ-108 | 폐기 뒤 새 거래의 연결 기준 제공 |
| 변경 사유 | 조직개편에 따른 이관 | 수정의 업무 근거 보존 |
| 요청·검토·승인자 | 담당 직책 또는 사용자 ID | 역할과 책임 확인 |
| 변경 버전 | MAP-2026-03-01-v2 | 전표에 적용된 규칙 재현 |
거래일과 승인일 중 어느 날짜를 매핑 기준으로 쓸지도 미리 정해야 합니다. 보통 비용의 귀속을 판단하는 날짜와 조직 관리 목적의 책임 기준일이 다를 수 있으므로, 한 날짜로 모든 코드를 결정하지 마세요. 회계처리와 관리회계 분류가 다르면 필드를 분리하는 편이 안전합니다.
승인된 지출결의서는 어떻게 수정 이력을 남기나요?
승인 뒤 핵심 값이 바뀌면 기존 문서를 삭제하지 않고 원 승인본 → 수정 요청 → 수정 승인본 → ERP 반영본으로 연결합니다.
수정 기록에는 다음 항목이 필요합니다.
- 원 결의번호와 원 ERP 전표번호
- 변경 전 값과 변경 후 값
- 변경 사유와 근거 자료
- 영향을 받는 금액·기간·예산·세무 구분
- 수정 요청자, 검토자, 승인자와 각 시각
- 적용한 코드 매핑 버전
- 기존 전표의 수정·취소·대체 여부
- 재처리 실행 ID와 최종 결과
외부감사법 제8조의 적용을 받는 회사는 내부회계관리규정에 회계정보의 오류 통제와 수정, 정기 점검·조정, 기록 관리와 업무 분장 등을 포함해야 합니다. 이 조항이 모든 회사에 동일한 시스템 구현을 요구하는 것은 아니지만, 적용 대상 회사라면 지출결의와 전표 수정 절차를 내부회계관리제도 범위에서 검토해야 합니다. 국가법령정보센터: 외부감사법 제8조
파일 업로드와 시스템 간 인터페이스는 무엇이 다른가요?
직접 인터페이스가 항상 더 정확하고 파일 업로드가 항상 수작업인 것은 아닙니다. 오류를 막는 기준은 전송 속도가 아니라 식별자, 검증, 승인, 재처리, 대사입니다.
| 방식 | 장점 | 주요 위험 | 반드시 확인할 통제 |
|---|---|---|---|
| 화면 직접 입력 | 소량 예외를 즉시 판단 가능 | 이중 입력, 담당자별 편차 | 입력 권한, 검토, 변경 이력, 전표번호 연결 |
| 표준 파일 업로드 | 다수 건을 같은 형식으로 처리 | 템플릿 버전 오류, 일부 행 실패, 중복 업로드 | 템플릿 버전, 사전 검증, 업로드 접수번호, 행별 결과, 파일 보관 |
| 배치 인터페이스 | 정해진 주기로 반복 전송 | 지연 발견, 부분 실패, 재실행 중복 | 실행 ID, 처리 구간, 성공·실패 분리, 재시작 위치 |
| 요청·응답 인터페이스 | 건별 결과를 빠르게 확인 | 타임아웃 뒤 성공 여부 불명, 순서 역전 | 멱등 키, 상태 조회, 재시도 규칙, 응답 기록 |
여기서 멱등 키는 같은 거래를 여러 번 요청해도 ERP 전표가 한 번만 생성되도록 식별하는 값입니다. 예를 들어 법인 ID + 결의번호 + 결의 버전 + 전표 유형을 조합할 수 있습니다. 실제 키는 취소·분할·합산 전표를 구분할 수 있도록 ERP 설계에 맞춰야 합니다.
전송 뒤에는 건수와 금액을 어떻게 대사하나요?
전송 성공 메시지만 확인하면 일부 행 누락이나 중복을 놓칠 수 있습니다. 같은 실행 ID 안에서 입력·성공·반려·보류 상태를 서로 겹치지 않게 정의하고 건수와 금액을 함께 대사해 주세요.
입력 건수 = 성공 건수 + 반려 건수 + 보류 건수
입력 금액 = 성공 금액 + 반려 금액 + 보류 금액
중복 반영 건수
= 같은 멱등 키에 연결된 유효 ERP 전표 수가 2개 이상인 거래 수예를 들어 한 실행에서 1,250건, 64,500,000원을 보냈다고 가정하겠습니다.
| 상태 | 건수 | 금액 | 다음 조치 |
|---|---|---|---|
| 성공 | 1,210 | 61,800,000원 | ERP 전표번호와 결의번호 연결 확인 |
| 반려 | 25 | 1,900,000원 | 오류 원인 수정 뒤 해당 행만 새 실행으로 재처리 |
| 보류 | 15 | 800,000원 | 승인·코드·증빙 보완 전까지 반영 금지 |
| 합계 | 1,250 | 64,500,000원 | 입력 합계와 일치 |
1,250 = 1,210 + 25 + 15
64,500,000 = 61,800,000 + 1,900,000 + 800,000이 수치는 계산 구조를 설명하기 위한 가정값이며 권장 오류율이나 업계 기준이 아닙니다. 금액 대사는 같은 통화와 같은 부호 기준으로 수행하고, 취소·부분취소·외화·분할 전표는 별도 유형으로 나눠야 합니다.
대사가 끝나도 다음 조건이 남으면 실행을 완료로 닫지 않습니다.
- ERP 전표번호가 없는 성공 건
- 같은 결의 버전에 유효 전표가 둘 이상 연결된 건
- 반려·보류 사유의 담당자와 기한이 없는 건
- 코드 유효기간 밖 거래
- 승인본과 ERP 반영 금액이 다른 건
- 취소 전표와 원 전표의 연결이 끊긴 건
재작성 비용은 어떻게 측정해야 하나요?
원문의 지출결의서를 몇 번 다시 만들었는지뿐 아니라 원인 확인, 재승인, 재업로드, 대사, 결산 지연까지 같은 사건 ID로 묶어 측정합니다.
월 재작업 직접비
= Σ(사건별 실제 재처리 시간 × 담당자 시간당 완전원가)
+ 추가 외부지원비
월 재작업 총비용
= 월 재작업 직접비
+ 재작업 때문에 실제로 발생한 결산 지연 비용
+ 오류 수정·보고서 재발행 비용예를 들어 월 120건을 건당 평균 20분씩 재처리했고 시간당 완전원가가 35,000원이라면 직접 인건비는 다음과 같습니다.
120건 × (20분 ÷ 60분) × 35,000원 = 1,400,000원여기에 이미 같은 20분에 포함된 검토 시간을 다시 더하면 안 됩니다. 결산 지연 비용도 실제 추가근무, 외부지원, 보고서 재발행처럼 관찰 가능한 금액만 분리해 기록해 주세요. 평균 시간은 담당자의 추정이 아니라 표본 사건의 시작·종료 기록으로 갱신하는 편이 좋습니다.
재작업 원인은 다음처럼 나누면 개선 순서를 정하기 쉽습니다.
| 원인 | 측정할 값 | 우선 개선 |
|---|---|---|
| 코드 유효기간 오류 | 건수, 재처리 시간, 영향 금액 | 유효일 검증과 코드 배포 절차 |
| 승인 뒤 분류 변경 | 재승인 건수, 대기시간 | 변경 중요도와 재승인 기준 |
| 파일 형식 오류 | 반려 행, 오류 유형 | 템플릿 버전과 사전 검증 |
| 일부 행 실패 | 성공·실패 혼재 실행 수 | 행별 결과와 선택 재처리 |
| 중복 전송 | 중복 후보와 취소 시간 | 멱등 키와 기존 상태 조회 |
| 마감 뒤 발견 | 정정 전표와 보고 영향 | 마감 전 예외 목록과 대사 |
ERP 전환 전에는 어떤 테스트를 해야 하나요?
정상 거래 한 건만 성공했다고 운영을 시작하면 변경과 실패 상황에서 다시 수작업이 늘어날 수 있습니다. 실제 운영에 들어가기 전에 아래 시나리오를 별도 실행 ID로 검증해 주세요.
- 정상 결의 1건과 여러 행을 가진 결의 1건
- 유효기간이 끝난 계정·부서·프로젝트 코드
- 승인 후 코드가 바뀐 결의
- 같은 요청을 두 번 보낸 경우
- 전송 중 타임아웃이 발생했지만 ERP에는 반영된 경우
- 파일 100행 중 일부 행만 반려된 경우
- 카드 거래의 전체 취소와 부분취소
- 마감 뒤 정정이 필요한 경우
- 인터페이스 중단 뒤 다시 시작하는 경우
- 원 시스템과 ERP의 건수·금액·전표번호 대사
각 시나리오에는 기대 결과, 실제 결과, 차이, 수정 담당자, 재시험 결과를 남깁니다. 운영 전환 기준도 정상 건 성공이 아니라 중복 0건, 미연결 성공 0건, 미해결 반려·보류 0건, 건수·금액 차이 0처럼 측정 가능한 값으로 정해 주세요.
NIST SP 800-53의 변경 통제 항목(CM-3)은 시스템 변경을 제안·검토·승인·구현·시험·기록하는 흐름을, 감사기록 항목(AU-3)은 사건 유형·시각·위치·발생 주체·결과·관련 주체를 남기는 기준을 제시합니다. 이는 국내 회계처리 의무를 정하는 법령이 아니라, ERP 변경과 처리 이력을 설계할 때 참고할 수 있는 정보시스템 통제 기준입니다. NIST SP 800-53 Rev. 5 및 2025년 Release 5.2.0 안내
운영 전환 체크리스트
- 카드 거래, 결의, 승인, 매핑, ERP 반영 ID가 서로 연결되나요?
- 계정·부서·프로젝트 코드에 유효기간과 변경 버전이 있나요?
- 승인 뒤 바뀌는 항목별 재승인 기준이 있나요?
- 파일·배치·요청별 실행 ID와 행별 결과를 확인할 수 있나요?
- 재전송 전에 기존 전표 상태를 조회하나요?
- 입력·성공·반려·보류 건수와 금액을 대사하나요?
- 일부 실패 건만 선택해 재처리할 수 있나요?
- 마감 전후의 정정 절차와 승인자가 정해져 있나요?
- 변경 전후 값, 사유, 승인, 반영 결과를 다시 재현할 수 있나요?
- 중단·복구·되돌림 기준과 담당자가 정해져 있나요?
자주 묻는 질문
승인 뒤 계정과목만 바뀌어도 결의서를 새로 작성해야 하나요?
기존 결의서를 처음부터 복제할 필요는 없습니다. 다만 계정과목 변경이 예산 책임, 세무 구분, 재무보고에 영향을 준다면 수정 버전을 만들고 회사 규정에 따른 검토·승인을 받아야 합니다. 기존 승인본과 변경 전후 값은 그대로 연결해 보존해 주세요.
시스템 간 인터페이스가 있으면 대사를 생략해도 되나요?
생략하면 안 됩니다. 요청이 성공한 것처럼 보였지만 일부 행만 실패하거나, 타임아웃 뒤 재시도로 중복 반영될 수 있습니다. 인터페이스 방식과 관계없이 실행별 건수·금액·전표번호를 대사해야 합니다.
파일 업로드 방식도 재작업을 줄일 수 있나요?
가능합니다. 템플릿 버전을 고정하고 업로드 전에 코드 유효기간·필수값·중복을 검사하며, 접수번호와 행별 처리 결과를 보관하면 됩니다. 전체 파일을 반복 업로드하지 않고 반려 행만 새 실행으로 처리하는 구조가 중요합니다.
ERP를 바꿀 때 과거 결의서를 모두 새 시스템에 다시 올려야 하나요?
먼저 전환 기준일과 이관 범위를 정해야 합니다. 미결·미지급·마감 전 거래처럼 새 시스템에서 후속 처리가 필요한 항목과 조회만 필요한 과거 자료를 분리하세요. 과거 전체를 신규 전표로 재생성하면 중복 장부가 생길 수 있으므로, 이관 전후 잔액과 전표 수를 대사하고 기존 시스템의 조회·보존 계획을 함께 정해야 합니다.
정리
ERP 변경으로 인한 법인카드 지출결의서 재작업은 특정 연동 기능 하나로 없어지지 않습니다. 카드 거래 원본과 승인본을 보존하고, 코드 매핑을 유효기간과 버전으로 관리하며, 변경 시점에 맞춰 수정·재승인·대체 전표를 선택해야 합니다.
마지막에는 실행별 성공·반려·보류 건수와 금액, ERP 전표번호, 중복 여부를 대사해 주세요. 이 통제가 갖춰져야 파일 업로드와 시스템 간 인터페이스 중 어떤 방식을 쓰더라도 재작업과 오류를 함께 줄일 수 있습니다.
