재무팀이 명확하게 설명할 수 있는 비용 승인 규칙

재무팀에 명확한 승인 규칙이 필요한 이유

«모든 비용은 관리자가 승인한다»처럼 단순한 규칙은 지출이 여러 팀, 예산, 금액 한도를 넘나들기 시작하면 제대로 작동하지 않습니다. 영업 관리자는 고객 식사가 필요한 이유를 이해할 수 있지만, 해당 비용 센터에 예산이 남아 있는지 또는 재무팀이 비용을 검토해야 하는지는 모를 수 있습니다.

명확한 비용 승인 규칙은 각 담당자에게 어떤 결정을 내려야 하는지 알려 줍니다. 요청자는 사실을 입력합니다. 예산 담당자는 지출이 자신의 비용 센터에 속하는지 확인합니다. 재무팀은 정책, 세금, 영수증, 더 높은 지출 한도를 검토합니다. 그러면 요청이 «확인해 주세요» 같은 모호한 문구가 오가는 이메일을 계속 순환하지 않고, 정해진 경로를 따라 진행됩니다.

지출 한도와 예산 소유권은 서로 다른 질문에 답합니다. 한도는 언제 추가 승인 단계가 필요한지를 정합니다. 예산 소유권은 어느 담당자의 예산에서 비용을 지급하는지를 나타냅니다. 부서 관리자가 해당 부서의 모든 예산을 자동으로 책임지는 것은 아닙니다. 한 사람이 팀을 이끌고 다른 사람이 구매 비용이 청구되는 프로젝트나 비용 센터의 자금을 관리할 수 있습니다.

예를 들어 직원이 고객 프로젝트를 위한 180달러짜리 소프트웨어 구독을 신청한다고 해 보겠습니다. 관리자는 업무상 필요성을 승인하고, 프로젝트 예산 담당자는 해당 프로젝트에 비용을 청구하는 것을 승인할 수 있습니다. 구독이 일반 정책을 벗어나는 경우에만 재무팀이 검토할 수도 있습니다. 금액이 3,500달러라면 재무 이사나 구매 검토자의 승인도 필요할 수 있습니다.

요청 화면을 만들기 전에 이런 결정을 먼저 합의하세요. 그렇지 않으면 실제 워크플로에는 비용 센터와 프로젝트 코드가 필요한데 양식에는 관리자 이름만 입력하게 될 수 있습니다. 이후 팀은 예외를 계속 추가하고, 그 결과 재작업과 혼란이 생깁니다.

규칙은 쉬운 말로 작성하세요. 각 규칙에는 다음 내용이 있어야 합니다.

• 금액, 비용 유형, 비용 센터처럼 승인을 시작하는 조건
• 누가 요청을 승인하며 무엇을 확인하는지
• 언제 두 번째 승인이 필요한지
• 일반 승인자가 없을 때 어떻게 처리하는지
• 예외를 승인할 수 있는 사람

재무팀, 관리자, 직원이 같은 방식으로 규칙을 해석해야 합니다. 정책에 합의한 뒤에는 AppMaster 같은 노코드 플랫폼으로 규칙 지도를 양식, 승인 프로세스, 알림으로 바꿀 수 있습니다. 이때 정책 결정을 화면 설계 뒤에 숨길 필요가 없습니다.

각 요청에 필요한 정보부터 정하기

승인자는 댓글로 세부 정보를 다시 요청하지 않고도 결정할 수 있을 만큼 충분한 맥락을 알아야 합니다. 재무팀은 양식을 만들거나 비용 승인 워크플로를 설정하기 전에 필요한 정보를 정해야 합니다.

대부분의 승인자는 직원이 무엇에 얼마를 쓰려는지, 왜 업무에 필요한지, 어느 예산에서 비용을 지급하는지, 정책을 따르는지를 알아야 합니다. 관리자는 업무 목적에 집중할 수 있습니다. 비용 센터 담당자는 예산을 확인합니다. 재무팀은 항목별 한도, 세금 증빙, 첨부 문서를 검토합니다.

각 요청에는 다음 기본 정보를 일관된 형식으로 기록해야 합니다.

• 세금 포함 여부를 표시한 총액과 통화
• 출장, 소프트웨어, 고객 식사, 사무용 장비 같은 비용 항목
• 비용 센터와 필요한 경우 프로젝트 또는 고객 코드
• 요청자, 부서, 결정을 받아야 하는 날짜
• 업무 목적, 공급업체, 견적서나 영수증 같은 문서

필수 필드는 실제 결정과 연결하세요. 25달러짜리 월간 소프트웨어 구독에는 공급업체, 금액, 비용 센터, 업무 목적만 필요할 수 있습니다. 4,000달러짜리 노트북 구매에는 사용 예정자, 교체 사유, 자산 요청 번호도 필요할 수 있습니다. 모든 요청에 하나의 긴 양식을 적용하면 데이터 품질이 떨어지고 직원이 불편을 느낍니다.

항목이나 금액에 따라 필요한 필드만 표시하세요. 출장 요청에는 목적지와 여행 날짜가 필요할 수 있습니다. 고객 접대에는 참석자 이름이 필요할 수 있습니다. 일정 금액을 초과하는 요청에는 여러 공급업체의 견적이나 특정 공급업체를 선택한 이유가 필요할 수 있습니다. 조건부 질문을 사용하면 직원이 왜 추가 정보를 입력해야 하는지 이해하기 쉬워집니다.

각 정보를 누가 입력할지도 정하세요. 요청자는 목적과 공급업체처럼 자신이 아는 사실을 입력해야 합니다. 양식은 직원 프로필에서 부서와 관리자를 자동으로 불러올 수 있습니다. 재무팀은 제출 후 정책 상태나 회계 코드를 추가할 수 있습니다. 직원이 확인할 수 없는 필드를 추측해서 입력하는 일을 막을 수 있습니다.

양식을 만들기 전에 최근 비용 요청 세 건에 이 목록을 적용해 보세요. 승인자가 이메일을 열거나 추가 질문을 하지 않고 결정할 수 있다면 정보가 충분한 것입니다. 그렇지 않다면 프로세스가 아직 문서 단계에 있을 때 누락된 필드를 추가하거나 표현을 명확히 하세요.

혼란 없이 승인 한도 매핑하기

금액 구간은 회사의 실제 지출 방식에 맞아야 합니다. 연간 소프트웨어 요금제를 주로 구매하는 팀과 직원이 주로 주행 거리, 식사, 소액 비품을 청구하는 팀은 서로 다른 한도가 필요합니다. 다른 회사의 한도를 그대로 복사하면 잘 맞지 않는 경우가 많습니다.

사람들이 기억할 수 있도록 짧은 구간을 사용하세요. 예를 들어 부서 관리자는 500달러 이하를 승인하고, 재무 관리자는 501달러에서 2,500달러까지 승인하며, 부서장은 그보다 큰 금액을 승인할 수 있습니다. 일반적으로 구간이 적을수록 전달 오류도 줄어듭니다.

각 구간 옆에 계산 기준을 적으세요. 한 사람은 세전 금액을 사용하고 다른 사람은 최종 결제 금액을 사용해 재무팀 내부에서 의견이 갈리는 일이 많습니다. 총액에 판매세, 팁, 환전 수수료, 반복 청구액이 포함되는지 명시하세요. 12개월 구독의 경우 첫 달 결제액을 기준으로 승인할지 전체 연간 약정액을 기준으로 승인할지도 정해야 합니다.

지출 유형도 중요합니다. 1,000달러짜리 고객 식사와 1,000달러짜리 노트북에 항상 같은 검토가 필요한 것은 아닙니다. 장비에는 IT 또는 구매팀 승인이 필요할 수 있지만, 일반 한도 안의 출장에는 직원 관리자 승인만 필요할 수 있습니다.

정책을 합의할 때는 다음과 같은 간단한 표를 사용하세요.

두 사람이 승인해야 할 때는 정확하게 정하세요. 순서대로 승인하는지 동시에 승인하는지, 결제 전에 두 사람의 결정이 모두 필요한지를 정의해야 합니다. 1,800달러짜리 소프트웨어 요청은 먼저 비용 센터 관리자에게 가고 그다음 재무팀으로 전달될 수 있습니다. 제한된 프로젝트 예산에 3,000달러를 청구하는 요청은 직원 관리자가 이미 승인했더라도 예산 담당자와 재무팀의 승인이 모두 필요할 수 있습니다.

한도 변경 권한은 재무팀이 관리해야 합니다. 양식 안에서 누구나 한도를 수정하거나 구두로 예외를 만들 수 있다면 워크플로를 설명하고 감사하기 어려워집니다. 현재 금액 구간을 하나의 정책 문서에 보관하고, 양식은 그 정책에 맞춰 만드세요.

비용 센터별 담당자 지정하기

모든 활성 비용 센터에는 이름이 정해진 예산 담당자가 한 명 있어야 합니다. 이 사람이 모든 구매를 직접 승인할 필요는 없지만, 직원과 재무팀은 해당 예산의 지출에 책임이 있는 사람이 누구인지 알아야 합니다. «부서장에게 보내기» 같은 규칙은 한 부서에 여러 팀이나 예산이 있을 때 지연을 일으킵니다.

요청의 비용 센터를 사용해 첫 승인자를 선택하세요. 영업 코디네이터가 북미 영업 비용 센터에 450달러의 행사 비용을 제출하면 요청은 해당 비용 센터 담당자에게 전달된 뒤 금액별 규칙을 따릅니다. 코디네이터가 어느 영업 리더가 예산을 관리하는지 추측할 필요가 없어야 합니다.

담당자 관리는 간단하게 유지하세요.

• 활성 비용 센터마다 주 담당자를 한 명 지정합니다.
• 여러 명을 동등한 담당자로 등록하기보다 대리 규칙으로 백업을 처리합니다.
• 공유 비용과 전사 비용에는 별도 경로를 설정합니다.
• 코드가 누락되었거나 비활성 상태인 요청은 재무팀 검토로 보냅니다.

공유 비용에는 명확한 경로가 필요합니다. 여러 부서가 사용하는 소프트웨어, 공동 사무용품, 회사 행사는 요청이 한 부서로 자동 배정될 때 갈등을 일으킬 수 있습니다. 재무팀은 이런 비용을 공유 서비스 담당자에게 배정하거나, 요청자에게 비용을 나누어 입력하게 하거나, 예산을 선택하기 전에 요청을 검토할 수 있습니다. 자주 발생하는 공유 지출 유형마다 한 가지 방식을 선택하세요.

양식에서 더 이상 존재하지 않는 코드를 선택할 수 없어야 합니다. 직원이 폐쇄된 프로젝트나 폐기된 팀 코드를 선택하면 요청을 중단하고 현재 비용 센터를 입력하도록 안내해야 합니다. 선택할 수 있는 비용 센터가 없다면 «비용 센터 누락» 같은 사유와 함께 재무팀에 요청을 보내야 합니다. 정책이 허용하는 경우 재무팀은 수정을 요청하거나 임시 코드를 지정할 수 있습니다.

비용 센터 이름, 코드, 주 담당자, 상태를 포함한 짧은 담당자 목록을 관리하세요. 예산이 이동하거나 팀이 재편되거나 담당자가 퇴사하면 목록을 업데이트해야 합니다. AppMaster 애플리케이션에서는 관리자가 데이터 테이블에서 이 목록을 관리하고 제출 요청을 자동으로 전달할 수 있습니다. 변경 권한은 재무팀이 유지하며, 더 이상 예산을 관리하지 않는 사람의 받은 편지함에 요청이 쌓이지 않습니다.

대리 승인과 부재 규칙 정하기

관리자가 휴가 중이거나 출장 중이거나 다른 역할로 이동했다는 이유로 승인이 멈춰서는 안 됩니다. 대리 승인을 사용하면 요청이 계속 진행되지만, 누가 왜 결정을 내렸는지 재무팀이 확인할 수 있도록 규칙에 제한을 둬야 합니다.

지정된 승인자가 직접 설정하거나 권한 있는 재무 또는 인사 관리자가 설정한 경우에만 대리 승인을 허용하세요. 대리 승인자의 이름, 시작일, 종료일을 기록해야 합니다. 기간이 정해지지 않은 대리 승인은 오래된 접근 권한이 계속 남는 문제를 일으킵니다.

실용적인 규칙으로는 부서 관리자가 예정된 휴가 기간 동안 최대 30일간 대리 승인자 한 명을 지정하도록 허용하는 방법이 있습니다. 부재가 더 길어지면 재무팀이 배정을 검토하고 갱신합니다. 이렇게 하면 대리 승인자가 여전히 적절한 권한을 갖고 있는지 확인할 시점이 생깁니다.

승인 기록을 명확하게 유지하기

워크플로에는 원래 승인자와 대리로 업무를 수행한 사람을 함께 표시해야 합니다. 대리 승인 기간과 승인 시간도 기록하세요. 나중에 재무팀이나 감사자가 비용 청구를 검토할 때 관리자가 직접 승인하지 않았고 대리 승인자에게 권한이 있었다는 사실을 확인할 수 있습니다.

원래 승인자의 이름을 대리 승인자의 이름으로 바꾸지 마세요. 이런 방식으로 단순화하면 특히 일반적인 지출 패턴을 벗어난 비용에서 분쟁을 해결하기 어려워집니다.

대리 승인자가 자신의 팀에서 제출한 비용 청구를 어떻게 처리할지도 명확히 정하세요. 일부 재무팀은 대리 승인자가 해당 팀의 일반적인 청구를 승인하도록 허용하지만, 대리 승인자 본인의 비용은 다른 관리자가 승인하도록 합니다. 다른 팀은 대리 관리자의 보고 라인에 속한 모든 청구를 상위 단계로 올립니다. 한 가지 정책을 선택하고 쉽게 이해할 수 있게 작성하세요.

대리 승인 정책에는 대리 승인자가 정해진 기간 동안 지정된 승인자를 대신해서만 행동하고, 자신의 비용을 승인할 수 없으며, 일반적인 금액 및 비용 센터 규칙을 따라야 한다는 내용이 포함되어야 합니다. 관리자가 퇴사하거나 역할을 바꾸면 재무팀은 대체 승인자를 지정해야 합니다.

역할 변경은 단기 부재와 다르게 처리해야 합니다. 퇴사자가 생기면 승인 권한을 즉시 회수하고 해당 비용 센터를 새 담당자에게 배정하세요. 영구 담당자가 아직 없다면 재무팀이 종료일이 있는 임시 담당자를 지정할 수 있습니다. 요청이 퇴사자의 대리 승인자에게 계속 전달되어서는 안 됩니다.

지연을 일으키기 전에 예외 경로 계획하기

모든 비용 승인 워크플로에는 일반 규칙에 맞지 않는 요청을 처리할 경로가 필요합니다. 화면을 만들기 전에 이런 사례를 정의하세요. 그렇지 않으면 직원은 이메일을 보내고 관리자는 비공식적으로 결정하며, 누구도 요청이 왜 승인되었는지 설명하지 못합니다.

일반적인 예외로는 긴급 출장, 영수증 누락, 일반 한도를 초과한 요청, 잘못된 비용 센터로 배정된 비용이 있습니다. 각각을 막연한 «특별 사유»가 아니라 이름이 정해진 예외 유형으로 관리하세요. 요청자는 사유를 선택하고 필요한 세부 정보를 첨부해야 합니다.

예를 들어 회의 날짜가 바뀌어 직원이 내일 고객 방문을 예약해야 할 수 있습니다. 이 요청에는 여행 일정, 긴급한 이유를 설명하는 짧은 메모, 예상 총액이 필요할 수 있습니다. 그러면 재무팀은 일반 승인 체인 대신 직원의 관리자와 재무 검토자에게 요청을 전달할 수 있습니다.

각 예외에 담당자 지정하기

각 예외를 누가 승인하고 어떤 증빙이 필요한지 정하세요. 영수증이 없으면 서명한 신고서와 카드 거래 기록이 필요할 수 있습니다. 긴급 구매라면 일반 구매 경로를 사용할 수 없었던 이유를 설명하는 관리자의 메모가 필요할 수 있습니다.

모든 예외 승인에 대해 최종 결정, 검토자 이름, 날짜, 재정의 사유를 기록하세요. 이렇게 하면 재무팀이 활용할 수 있는 감사 기록이 남고 반복되는 정책 문제를 파악하는 데 도움이 됩니다.

응답 기한과 에스컬레이션 추가하기

검토자가 자리를 비우거나 알림을 놓치면 요청이 멈추는 경우가 많습니다. 각 예외에 응답 기한을 설정하세요. 기한이 지나면 워크플로가 대리 승인자에게 알리거나 지정된 백업 검토자에게 에스컬레이션해야 합니다.

긴급 출장의 경우 첫 번째 검토자에게 영업일 기준 하루의 응답 시간을 줄 수 있습니다. 응답하지 않으면 요청을 대리 승인자에게 보냅니다. 대리 승인자도 근무 시간 기준 네 시간 안에 응답하지 않으면 재무팀이 결정을 내리도록 합니다. 최초 검토자를 계속 표시해 재무팀이 지연이 어디서 시작됐는지 확인할 수 있게 하세요.

애플리케이션에는 예외 유형, 증빙 자료, 재정의 사유, 에스컬레이션 상태를 저장해야 합니다. AppMaster에서는 팀이 이러한 필드를 모델링하고 시각적 비즈니스 프로세스를 통해 요청을 전달할 수 있습니다. 직원에게는 정당한 예외를 처리할 명확한 경로가 생기고, 재무팀은 일관된 기록을 유지할 수 있습니다.

실제 요청을 따라가며 확인하기

마케팅 코디네이터가 1,200달러짜리 연간 소프트웨어 구독을 신청한다고 해 보겠습니다. 양식에는 공급업체, 금액, 업무 목적, 갱신일, 마케팅 비용 센터를 입력합니다. 코디네이터는 공급업체 견적서를 첨부하고 이 도구가 캠페인 보고를 지원한다고 설명합니다.

워크플로는 알림을 보내기 전에 금액과 비용 센터를 확인합니다. 합의된 규칙에 따르면 1,000달러에서 2,500달러 사이의 구매에는 비용 센터 담당자와 재무 검토자의 승인이 필요합니다. 요청은 먼저 마케팅 예산 담당자에게 전달됩니다.

담당자는 요청 내용, 남은 비용 센터 예산, 구매 사유를 확인합니다. 승인하거나 거부하거나 질문과 함께 반려할 수 있습니다. 승인하면 재무팀이 동일한 기록을 받습니다. 재무팀은 구독이 정책에 맞는지, 세금 정보가 있는지, 해당 공급업체가 기존 기록에 등록되어 있는지를 확인합니다.

두 사람이 모두 승인하면 시스템은 결정, 승인자 이름, 타임스탬프를 기록합니다. 코디네이터는 상태 업데이트를 받고 구매를 진행할 수 있습니다. 재무팀이 거부하면 «현재 계약이 끝날 때까지 기존 보고 도구를 사용하세요»와 같은 사유가 기록에 남습니다.

비용 센터 담당자가 자리를 비운 경우

마케팅 담당자가 휴가 중이라면 담당자가 미리 대리 승인을 설정했고 해당 기간이 휴가 날짜와 겹칠 때만 대리 승인자가 행동할 수 있습니다. 대리 승인자는 자신이 마케팅 담당자를 대신하고 있다는 안내를 받습니다.

대리 승인자는 같은 결정을 내릴 수 있지만 기록에는 권한을 가진 원래 담당자와 실제로 행동한 사람이 모두 표시되어야 합니다. 대리 승인자가 승인한 뒤에도 재무팀은 요청을 검토합니다. 대리 승인자는 자신의 비용을 승인하거나 더 높은 승인 한도를 우회할 수 없습니다.

요청에 예외가 필요한 경우

공급업체가 일반 검토가 끝나기 전에 결제를 요구하거나 구매가 정책 한도를 벗어나면 코디네이터가 예외를 요청할 수 있습니다. 양식에는 짧은 예외 사유와 공급업체 견적서에 적힌 마감일 같은 증빙 자료를 요구해야 합니다.

그런 다음 워크플로는 해당 예외를 승인할 권한이 있는 사람, 보통 재무 관리자에게 요청을 보냅니다. 예외 결정은 일반 승인 절차를 대체하지 않고 그 옆에 기록됩니다. 예를 들면 다음과 같습니다. «예외 승인: 행사 등록이 금요일에 마감되므로 일반 조건보다 먼저 결제할 수 있습니다.»

이 사례는 혼란이 자주 발생하는 금액 한도, 소유권, 임시 대리, 예외를 모두 확인합니다. 모든 경로에 담당자와 기록된 결과가 정해진 뒤에 제출 화면을 만드세요.

흔한 승인 규칙 실수 피하기

많은 승인 워크플로가 예산 소유권이 아니라 조직도를 그대로 따르기 때문에 실패합니다. 직책만으로는 전체 상황을 알기 어렵습니다. 한 관리자가 두 개의 비용 센터를 운영하거나, 일시적으로 예산을 맡거나, 특정 지출 항목만 승인할 수 있습니다. «부서장» 같은 직책이 아니라 사람, 비용 센터, 항목, 한도에 승인 권한을 연결하세요.

모든 요청을 재무 이사에게 보내지 마세요. 일반 구매까지 대기열에 쌓여 재무팀이 병목이 됩니다. 재무팀은 정책을 정하고 특이한 위험을 검토하며 선택된 예외를 처리해야 합니다. 비용 센터 담당자는 합의된 한도 안에서 일반 지출을 승인하고, 더 큰 금액이나 제한된 항목은 다음 단계로 보내면 됩니다.

예외 규칙을 이메일이 아니라 워크플로 안에 두세요. 항공편 취소로 직원이 당일 호텔을 예약해야 한다면, 사유를 기록하고 증빙을 첨부해 올바른 승인자에게 보내고 결정을 기록하는 경로가 보여야 합니다.

다음 몇 가지 확인만으로 대부분의 혼란을 막을 수 있습니다.

• 직책만이 아니라 예산 책임에 따라 승인 권한을 지정합니다.
• 일반 요청에는 한도를 설정하고 예외에는 별도 경로를 둡니다.
• 부재 시 대체 방법과 각 대리 승인 기간을 정의합니다.
• 재무 이사 승인은 필요한 금액, 항목, 예외에만 적용합니다.
• 요청자가 최종 승인자를 직접 선택하지 못하게 합니다.

마지막 규칙은 이해 상충으로부터 프로세스를 보호합니다. 요청자는 비용을 청구할 비용 센터를 선택할 수 있지만, 워크플로는 승인된 규칙에 따라 승인자를 선택해야 합니다. 영업 관리자가 영업 비용 센터로 900달러의 고객 식사를 신청하면 친한 관리자 목록이 아니라 해당 예산 담당자에게 요청이 전달되어야 합니다.

사람들이 테스트하고 설명할 수 있는 언어로 규칙을 작성하세요. 예를 들면 다음과 같습니다. «5,000달러를 초과하는 요청에는 비용 센터 담당자와 재무팀의 승인이 필요합니다. 긴급 상황으로 예약한 출장에는 사전 승인을 생략할 수 있지만, 직원은 영수증과 서면 사유를 영업일 기준 이틀 안에 제출해야 합니다.»

양식을 만들기 전에 빠르게 확인하기

불명확한 규칙은 양식으로 해결할 수 없습니다. 재무팀, 예산 담당자, 운영 담당자가 쉽게 읽을 수 있는 짧은 문서에 승인 지도를 정리하세요.

소유권부터 시작하세요. 모든 활성 비용 센터에는 이름이 정해진 승인자와 부재 시 사용할 백업 경로가 필요합니다. 회사가 해당 역할 목록을 최신 상태로 관리하지 않는다면 «부서 리더» 같은 표현을 피하세요. 마케팅 비용 센터에 담당자가 없다면 요청을 중단할지, 재무팀으로 보낼지, 임시 대리 승인자에게 전달할지 결정해야 합니다.

각 한도를 최근 요청과 비교하세요. 지난달이나 지난 분기의 요청을 금액, 비용 센터, 비용 유형별로 정렬해 소량을 검토합니다. 이렇게 하면 합리적으로 들리지만 불필요한 승인을 만드는 규칙을 찾을 수 있습니다. 대부분의 소프트웨어 갱신 금액이 500달러 한도를 조금 넘는다면 재무팀은 특이한 지출보다 일반적인 비용 승인에 너무 많은 시간을 쓰게 됩니다.

다음처럼 까다로운 사례로 작성한 규칙을 테스트하세요.

• 일반 담당자가 있는 활성 비용 센터에 청구하는 1,200달러 호텔 요청
• 비용 센터 담당자가 휴가 중일 때 제출된 요청
• 일반 한도를 초과하지만 더 빠른 예외 경로가 필요한 긴급 수리
• 유효한 비용이지만 비용 센터가 없거나, 현재 담당자가 없는 비용 센터

각 사례의 예상 결과를 적으세요. 누가 요청을 받고, 누가 승인할 수 있으며, 어떤 증빙이 필요하고, 아무도 응답하지 않으면 어떻게 되는지를 기록합니다. 두 사람이 같은 사례를 다르게 해석한다면 규칙을 더 다듬어야 합니다.

팀이 양식을 설계하기 전에 재무팀과 예산 담당자에게 문서를 승인받으세요. 승인은 문구뿐 아니라 금액, 전달 순서, 대리 승인 한도, 예외 승인 권한까지 포함해야 합니다. 나중에 변경할 때 참고할 수 있도록 승인된 버전을 워크플로 구축 자료와 함께 보관하세요.

합의된 규칙으로 워크플로 만들기

재무팀이 전달 지도를 승인하면 각 규칙을 애플리케이션이 저장하고 실행할 수 있는 데이터로 바꾸세요. 요청에는 금액, 통화, 비용 센터, 비용 유형, 요청자, 업무 사유, 영수증, 날짜 같은 필드가 필요합니다. 직원에게는 초안, 제출됨, 관리자 승인 대기, 재무팀 승인 대기, 승인됨, 거부됨, 수정 필요처럼 명확한 상태도 보여 줘야 합니다.

정책과 화면 레이아웃을 분리하세요. 한도를 500달러에서 750달러로 바꾸거나 새로운 비용 센터 담당자를 지정할 때 모든 양식을 다시 만들지 말고 규칙만 변경할 수 있어야 합니다.

제출 화면보다 먼저 전달 경로 만들기

먼저 전달 조건을 만드세요. 250달러 미만의 요청은 비용 센터 관리자에게 보낼 수 있습니다. 250달러에서 2,000달러 사이의 요청에는 관리자와 재무팀의 승인이 필요할 수 있습니다. 2,000달러를 초과하는 요청에는 부서장의 승인도 필요할 수 있습니다. 고객 접대는 금액과 관계없이 영수증과 재무팀 검토가 필요할 수 있습니다.

재무 담당자가 규칙을 열어 애플리케이션이 왜 특정 승인자를 선택했는지 이해할 수 있어야 합니다. AppMaster에서는 요청을 저장하고, 필수 필드를 확인하고, 비용 센터 담당자를 찾고, 금액을 평가하고, 적절한 승인 작업을 만드는 시각적 비즈니스 프로세스를 만들 수 있습니다. 역할 기반 접근 권한으로 각 승인자가 자신이 봐야 하는 요청만 열도록 제한할 수도 있습니다.

로직이 안정된 뒤 제출 화면을 만드세요. 전달 규칙과 재무 검토에 필요한 정보와 관련 문서를 수집하면 됩니다. 질문이 지나치게 많으면 입력이 느려지고 답변도 일관되지 않기 쉽습니다.

실제로 제출되는 요청으로 테스트하기

출시 전에 재무팀은 애플리케이션에서 현실적인 사례를 테스트해야 합니다.

• 일반 운영 비용 센터에 청구하는 90달러 소프트웨어 구독
• 관리자와 재무팀의 검토가 필요한 600달러 호텔 비용
• 추가 승인이 필요한 3,500달러 장비 요청
• 일반 승인자가 부재 중일 때 제출된 요청
• 영수증이 없어 재무팀이 수정을 요청하는 비용

각 테스트에서 지정된 승인자, 요청자에게 표시되는 상태, 알림 시점, 감사 기록을 확인하세요. 재무팀이 경로를 한두 문장으로 설명할 수 없다면 직원이 사용하기 전에 규칙을 단순화하세요.

테스트가 끝나면 워크플로를 게시하고 요청자에게 자신이 보게 될 상태를 간단히 안내하세요. 명확한 비용 승인 규칙은 누군가의 받은 편지함에 숨은 결정이 아니라 예측 가능한 단계가 됩니다.