용역 프로젝트 ERP 구축: 계약 마일스톤과 청구·입금을 연결하는 법

용역 프로젝트 ERP 구축은 계약에서 정한 청구 조건과 산출물 검수 증거를 연결하고 청구 가능한 금액, 이미 청구한 금액과 실제 입금을 구분해 보여주는 일입니다. 일정 완료율이나 투입 시간만으로 청구 가능 여부를 자동 확정하면 계약 조건이 빠집니다. 기존 회계 ERP의 청구·입금 원장을 유지하면서 미청구 업무를 확장할 범위를 먼저 정하세요.

컨설팅 결과물을 전달한 담당자는 일을 끝냈다고 생각하지만 경영지원팀은 청구 요청을 받지 못했습니다. 고객의 검수 회신은 이메일에 있고 계약서는 파일함에 있어 누구도 청구 가능 상태를 확정하지 못합니다. 반대 경우도 있습니다. 일정표에서는 한 단계를 완료했지만 계약상 별도 승인이 남아 있는데 매출 예정표에는 청구 완료로 올라갑니다. 이런 단절을 줄이는 구조가 용역 프로젝트 ERP의 발주 대상입니다.

이 글은 컨설팅·디자인·연구 용역을 수행하는 가상 회사의 운영 모듈을 다룹니다. 건설 하도급 원가나 일반 업무 일정 관리, 개인 근태와 생산성 평가는 제외합니다. 청구 조건의 법적 해석, 수익 인식과 세금계산서 발행 시기의 판단도 시스템이 대신하지 않습니다. 담당자가 승인한 계약 조건을 기록하고 그 조건에 맞는 증거와 청구·입금 관계를 연결하는 범위로 한정합니다.

프로젝트 화면에서 계약금액, 청구예정, 미청구, 미수라는 숫자를 함께 보여줄 때 각 뜻을 적어두세요. 청구일이 아직 오지 않은 계약 잔액과 조건은 충족했지만 아직 청구하지 않은 잔액은 다릅니다. 이미 발행한 청구 중 입금을 받지 못한 금액도 별도입니다. 어느 금액이 어느 계약판과 기준시각을 사용했는지 확인할 수 있어야 부서마다 다른 합계를 보고도 원인을 찾습니다.

공식 제품 문서도 청구제안과 청구 확정을 구분합니다#

Microsoft Project Operations의 제조 기반 시나리오용 공식 문서는 고정금액과 공수형 프로젝트의 청구 기준을 나누고, 확정 전에 검토할 청구제안을 설명합니다. 고정금액의 청구 일정에는 계약상 마일스톤 등을 연결할 수 있다고 명시합니다. 이는 유형별 기준과 검토 단계를 구분할 참고 사례입니다. 모든 용역 계약에 같은 절차가 적용되거나 고객 검수의 법적 의미가 확정된다는 근거는 아닙니다. 아래 미청구 계산과 운영 흐름은 가상 발주 제안입니다.

• Microsoft Learn: Project invoicing: 제조 기반 시나리오에서 공수형·고정금액·청구제안·마일스톤을 설명합니다. 회계·세무·계약 해석은 별도 확인합니다.

부분 검수와 변경계약은 승인판을 나눠 처리합니다#

중간 산출물의 일부만 확인받은 경우 원래 단계 30을 통째로 완료 처리하지 않습니다. 계약상 부분 청구가 가능한지 책임자가 확인하고, 가능한 경우 승인된 하위 범위와 금액 15를 기록하는 식으로 구분합니다. 나머지 15는 보완 또는 확인대기로 남습니다. 부분 청구를 허용하지 않는 계약이라면 단계 전체를 보류하는 정책도 가능합니다. 시스템이 임의 비율로 청구 가능액을 만드는 기능은 요구사항에서 제외하세요.

추가 요청이 들어오면 원계약 C1과 변경 제안 C2를 분리합니다. C2의 검토 중 금액을 합계에 먼저 넣으면 내부 계획과 고객 합의가 섞입니다. 승인 뒤 유효한 계약판과 적용 대상 산출물을 연결하고 이미 청구한 부분에 영향을 주는지 확인합니다. 계약판만 교체하고 기존 청구 연결을 모두 새판으로 옮기면 과거 청구 근거를 잃으므로 원본과 차이표를 보존하는 방안을 요구합니다.

청구 확정 전에 취소된 제안은 재작성할 수 있지만 외부 청구나 회계 ERP 반영을 마친 문서는 다른 경로가 필요합니다. 원문을 삭제해 미청구를 되살리는 식으로 처리하지 말고 정정·취소의 업무 승인을 받아 원청구와 후속 문서를 연결합니다. 이미 받은 입금이 있다면 대사 담당자가 반환·재배부 등 후속 경로를 정합니다. 어떤 정정이 가능한지 제품과 계약 조건에 따라 달라지므로 공통 자동 처리로 약속하지 않습니다.

연동 오류는 요청 접수와 회계 반영을 나눠 보여줍니다. 회계 ERP가 응답하지 않았다고 새 청구번호를 계속 발급하면 중복 청구가 생길 수 있습니다. 원 요청 ID로 기존 반영 여부를 확인한 뒤 재처리하도록 설계하세요. 기술 담당은 전달을 복구하고 업무 담당은 청구 근거를 검토합니다. 프로젝트 책임자, 청구 승인자와 입금 확인자의 대체 담당까지 지정하면 미청구 건이 개인 메일함에만 남지 않습니다.

제안 비교와 인수는 같은 계약 표본으로 진행합니다#

기존 ERP의 프로젝트 청구 기능 설정, 협업 도구에 검수·청구 요청만 추가하는 안, 별도 용역 운영 모듈을 개발하는 안을 비교하세요. 일정 관리 도구는 산출물 작업에 적합해도 청구와 입금 정본은 다른 시스템에 남을 수 있습니다. 제안서에는 각 정본, 연결 ID와 실패 복구 책임을 명시합니다. 표준 기능과 추가 개발의 구분 없이 프로젝트 관리 일체로 묶은 견적은 범위를 확인하기 어렵습니다.

견적 입력자료는 계약 유형별 표본, 단계·산출물·검수 조건, 시간과 비용의 청구 규칙, 변경계약과 청구 정정 사례입니다. 사용하는 회계 ERP와 문서·전자발행 경로의 접근 조건도 필요합니다. 실제 계약서를 외부로 제공하기 어렵다면 문구를 가리되 상태와 연결 관계는 보존하세요. 계약 조건 표준화, 과거 미청구 정리, 데이터 이관과 연동 개발·운영 교육은 각각의 산출물로 구분합니다.

검수에서는 C1 금액100, 청구조건충족35, 기청구20, 입금12를 넣어 미청구15·미수8·미충족65가 나오는지 확인합니다. 이어 중간 검수 승인을 철회하거나 청구제안을 취소해 같은 계약 범위가 두 번 청구되지 않는지 보세요. 이미 확정된 청구에 영향을 주는 철회는 경고·검토 대상으로 남아야 합니다. ERP 전달을 실패시킨 뒤 재실행해도 문서가 한 번만 생성되는지 확인합니다.

인수의 마지막 단계에서는 신규 담당자가 계약판에서 검수 증거, 청구 문서와 입금 배부까지 찾아가게 합니다. 월말 목록에는 미청구의 이유와 다음 행동, 책임자가 남아 있어야 합니다. 아직 합의하지 않은 추가 용역은 예상 항목으로 별도 표시하고 운영 관리값을 결산 확정값처럼 내보내지 않는지도 점검하세요. 실제 송금이나 청구 발행을 하지 않는 검수 환경에서 대표 예외를 재현하고 결과표를 보관합니다.

계약판이 달라진 뒤 청구제안을 다시 만드는 상황도 확인합니다. 같은 계약행이 이전 제안과 새 제안에 동시에 남으면 화면별 합계는 그럴듯해도 실제 발행 단계에서 중복될 수 있습니다. 확정된 제안, 취소된 제안과 다시 작성한 제안의 관계를 보존하고 현재 청구 대상에서 제외된 이유를 표시하세요. 승인 직전에 계약 조건이 바뀌면 오래 열린 화면에서도 유효한 계약판을 다시 확인하는지 봅니다.

인수자료에는 보고서의 포함 조건을 적습니다. 고객 검수는 끝났지만 내부 청구 승인이 없는 건, 내부 승인은 됐지만 ERP 반영이 실패한 건과 발행됐지만 입금이 없는 건을 각기 다른 목록으로 전달합니다. 담당자는 합계가 맞다는 설명뿐 아니라 한 행을 다음 상태로 옮기는 근거를 찾아야 합니다. 보고서 내보내기에도 기준시각·계약판·상태 조건을 남기면 부서 간 대사에 사용할 수 있습니다.

공수 입력과 승인 범위는 타임시트 시스템의 시간 구분에서 별도로 확인하세요. 일정과 업무 기준선은 프로젝트 일정·산출물 관리과 연결합니다. 건설 하도급과 현장 원가는 건설 프로젝트 원가 ERP의 다른 의도입니다.