영수증 사진으로 더 빠른 승인까지 — 비용 환급 앱

서류 작업 문제, 쉽게 풀어 설명하면

영수증 쫓기는 보통 사소한 일에서 시작됩니다. 누군가 택시비를 내고 종이 영수증을 주머니에 넣어두었다가 나중에 제출하려고 합니다. 일주일이 지나면 영수증이 희미해지거나 사라지고, 청구는 메시지 스레드로 바뀝니다.

대부분의 문제는 세 가지에서 옵니다: 영수증을 잃어버리거나(또는 아예 수집하지 않음), 규칙이 불명확하게 느껴짐(무엇에 영수증이 필요한지, 언제 메모가 필요한지, 어떤 한도가 적용되는지), 그리고 승인이 느림(매니저가 바쁘거나 재무가 질문을 하며 청구가 미완료 상태로 남음).

각자가 느끼는 불편은 다르지만 모두가 체감합니다. 직원은 이미 쓴 돈을 환급받으려고 기다리고, 매니저는 빠르게 승인하기보다 누락된 정보를 묻느라 시간을 씁니다. 재무는 합계를 다시 입력하고 카드 명세와 맞추며 월말 직전에 사람들을 쫓아다닙니다.

영수증 사진을 중심으로 한 간단한 지출 앱은 올바른 행동을 가장 쉬운 행동으로 만들어 이 문제를 해결합니다. 제출은 1분 이내, 매니저는 굳이 파고들지 않아도 결정할 수 있는 충분한 맥락을 제공받아야 합니다. 재무는 수작업 정리가 필요 없는 깔끔한 숫자를 얻어야 합니다.

여기서 만드는 워크플로우는 다음과 같습니다:

• 직원이 영수증 사진과 몇 가지 핵심 필드를 포함해 비용을 제출합니다.
• 앱은 기본 규칙을 확인합니다(영수증 누락, 한도 초과, 잘못된 카테고리 등).
• 매니저는 승인하거나 명확한 질문과 함께 반려합니다.
• 재무는 예외를 검토한 뒤 깔끔한 월별 합계를 내보냅니다.
• 직원은 환급을 받고 언제든 상태를 확인할 수 있습니다.

노코드 플랫폼(예: AppMaster)으로 이걸 만들면 목표는 동일합니다: “영수증이 어디 있지?”라는 상황을 줄이고 월말 난장판 대신 예측 가능하고 추적 가능한 프로세스를 만드는 것입니다.

필요할 역할과 권한

지출 도구를 공정하게 느끼게 하는 가장 빠른 방법은 누가 무엇을 할 수 있는지 명확히 하는 것입니다. 단순한 역할 설정은 두 가지 흔한 문제를 방지합니다: 승인 후 항목을 누가 수정하는 문제, 그리고 재무가 몇 주 동안 누락된 세부사항을 쫓아다니는 문제입니다.

처음에는 네 가지 역할로 시작하세요. 권한은 처음엔 엄격하게 유지하고 실제 필요가 생길 때만 예외를 추가하세요.

• Employee (청구 소유자): 청구를 만들고 영수증 사진을 추가하며 초안 상태에서는 편집할 수 있습니다. 제출 후에는 질문에 답하고 추가 파일을 첨부할 수 있지만, 청구가 초안으로 되돌려지지 않는 한 금액은 변경하지 못하게 합니다.
• Manager (승인자): 검토하고 승인하거나 거부하며 간단한 메모로 변경을 요청할 수 있습니다. 많은 팀은 휴가 중 승인이 멈추지 않도록 위임(delegate) 옵션을 필요로 합니다.
• Finance (감사 담당): 모든 것을 볼 수 있고 샘플 검토로 영수증을 확인하며 원본 영수증 이미지를 바꾸지 않고 코딩(코스트센터나 카테고리)을 수정할 수 있습니다. 재무는 마감한 월을 잠가 보고 이후 합계가 변경되지 않게 해야 합니다.
• Admin (설정 관리자): 사용자, 팀, 코스트센터, 환급 방법 및 정책 규칙을 관리합니다. 기본적으로 Admin이 자신의 비용을 승인하지 못하게 하세요.

작지만 중요한 규칙: “볼 수 있다(can see)”는 권한과 “바꿀 수 있다(can change)”는 권한을 분리하세요. 매니저는 보통 팀의 청구를 볼 필요는 있지만 직원의 설명을 편집하거나 영수증을 교체할 필요는 없습니다.

초기에 몇 가지 예외 권한을 정의하세요:

• 누가 다른 사람을 대신해 제출할 수 있는가(비서 등)?
• 누가 민감한 가맹점(의료, 법률 등)을 볼 수 있는가?
• 누가 반려된 청구를 다시 열 수 있는가?

AppMaster에서는 역할을 화면과 액션에 매핑하고 동일한 규칙을 웹과 모바일에서 재사용할 수 있어 이 작업을 쉽게 할 수 있습니다.

직원이 제출해야 할 것(선택 항목은 무엇인지)

사람들이 지출 도구를 싫어하게 만드는 가장 빠른 방법은 매번 완전한 "지출 보고서"를 요구하는 것입니다. 더 나은 패턴은: 직원이 개별 비용을 추가하면(한 장의 영수증 = 한 라인), 앱이 이를 주간·출장·월간 단위로 자동으로 묶어 보고서를 만듭니다. 매니저는 보고서를 승인하지만, 문제가 있어 보이면 개별 라인 항목을 열어볼 수 있습니다.

각 비용 라인에서는 필수 필드를 최소화해 제출이 1분 이내로 끝나게 하세요:

• 구매일자
• 상점(merchant)
• 금액
• 통화
• 카테고리(식대, 숙박, 택시, 소모품 등)

나머지는 처음엔 선택사항으로 두되, 팀이 필요하면 나중에 추가 가능하게 하세요. 영업팀은 고객명을 원할 수 있고 운영팀은 코스트센터를 원할 수 있습니다. 모두에게 의무화하면 ‘N/A’, ‘기타’ 같은 쓸모없는 데이터가 쌓입니다.

자주 유용한 선택 필드에는 프로젝트 코드, 고객, 코스트센터, 결제수단(개인카드 vs 법인카드) 등이 있습니다. AppMaster를 사용하면 기본 항목으로 시작해 흐름을 깨지 않고 나중에 필드를 추가할 수 있습니다.

영수증 사진은 핵심입니다. 하지만 한 가지 규칙을 모두에게 강요할 필요는 없습니다. 대부분의 회사에 적용할 수 있는 두 가지 간단한 정책:

• 특정 카테고리(숙박, 항공 등)는 항상 영수증 필수
• 일정 금액 이상일 때만 영수증 필수(예: $25 초과)

또한 “영수증 없음”을 간단한 사유와 함께 허용하되 범위를 제한하세요. 이렇게 하면 워크플로우는 멈추지 않으면서도 재무가 통제권을 유지할 수 있습니다.

제출에서 환급까지의 명확한 워크플로우

좋은 지출 흐름은 지루할 정도로 안정적이어야 합니다. 직원은 무엇을 해야 할지 알고, 매니저는 빠르게 결정하며, 재무는 사람들을 쫓지 않고 월을 마감할 수 있어야 합니다.

‘비용(expense)’이 어디에 속하는지 결정하세요. 대부분의 팀은 비용을 보고서(출장, 월간, 프로젝트) 안에 두는 것이 좋습니다. 이렇게 하면 사람들이 일회성 항목 대신 묶음으로 제출합니다.

직원 흐름은: 보고서 생성 → 비용 하나씩 추가 → 영수증 촬영 또는 업로드 → 모든 것이 준비되면 제출. 양식을 짧게 유지해 영수증 사진이 대부분을 설명하게 하세요.

제출되면 매니저는 세 가지 명확한 행동을 해야 합니다: 승인, 반려, 또는 설명 요청. ‘설명 요청’은 재제출을 줄이는 핵심입니다. 직원에게 간단한 질문을 보내고 보고서를 그대로 유지해 누락된 것만 고치게 하세요.

재무는 모든 항목을 두 번 검토하지는 않아야 합니다. 고액, 특정 카테고리, 누락 필드 같은 항목만 샘플로 검사하세요. 재무는 정책을 집행하고 환급이 ‘지급됨(Paid)’으로 표시되기 전에 최종 확인을 합니다.

상태를 어디서나 볼 수 있게 하고 기록 로그에 숨기지 마세요. 보통 네 단계면 충분합니다:

• Draft(초안, 직원만 볼 수 있음)
• Submitted(매니저 대기 중)
• Approved(매니저 및 재무 완료)
• Paid(환급 완료)

AppMaster로 구축하면 상태 변경, 알림, 권한을 일관되게 유지할 수 있도록 워크플로우 로직을 한 곳(단일 비즈니스 프로세스)에 모아두세요.

먼저 설계할 화면(최소한으로 유지)

대부분의 지출 앱은 처음 몇 화면에서 사용자 경험이 결정됩니다. 각 화면은 작고 빠르며 한 가지 작업에 집중하게 하세요. 기본이 느리면 사용자들이 앱 사용을 중단합니다.

직원(모바일): 1분 이내 제출

누군가 택시나 공항 줄에서 쓸 수 있게 ‘새 비용(New expense)’ 흐름부터 시작하세요. 사진을 찍고 금액을 입력하고 카테고리를 선택하고, 정보가 없으면 초안으로 저장할 수 있게 하세요.

출시 초기 필수 항목:

• 새 비용 폼(merchant, 날짜, 금액, 카테고리)
• 카메라 업로드와 명확한 ‘재촬영’ 옵션
• 초안 목록(도중에 잃어버리지 않도록)
• 상태 보기(추측하지 않게)
• 메모 필드(선택사항)

매니저: 모든 영수증을 열지 않고 승인

매니저는 ‘오늘 내가 처리할 것’이 무엇인지 알려주는 큐가 필요합니다. 단순한 필터(팀, 날짜 범위, 정책 초과 등)를 추가하고 승인·거부를 원탭으로 만들세요. 코멘트는 빠르게 입력할 수 있게 하고, 제안 문구(예: “프로젝트 코드 추가하세요” 또는 “항목화된 영수증 필요”)를 제공하면 좋습니다.

알림은 선별적으로 보내세요: 비용 제출 시(또는 주간 배치 도착 시) 한 번, 승인 또는 수정 요청 시 한 번. 초안의 작은 수정마다 과도하게 알림을 보내지 마세요.

재무: 추적과 월 마감에 집중

재무는 직원별, 코스트센터별, 카테고리별 합계가 보이는 월간 뷰와 누락 필드나 정책 위반 예외 목록이 필요합니다. AppMaster로 만든다면 팀의 마감 방식에 맞춘 내보내기 화면(기간 선택기, 검토 테이블, 예외 해소 후 한 번의 내보내기)을 설계하세요.

성장해도 깔끔한 데이터 모델

좋은 데이터 모델은 직원이 늘고 정책이 복잡해진 뒤에도 앱을 단순하게 유지합니다. 핵심 엔티티를 작고 예측 가능하게 유지하고 정말 필요할 때만 선택 필드를 추가하세요.

사람들이 실제로 일하는 방식에 맞춘 몇 가지 테이블로 시작하세요:

• Users: 역할과 코스트센터/팀 정보
• Reports: 출장 또는 월 단위 보고서, 소유자, 상태(Draft, Submitted, Approved, Paid)
• Expenses: 보고서 내 라인 항목(날짜, 상점, 금액, 통화, 카테고리, 메모)
• ReceiptFiles: 비용에 연결된 파일 레코드(파일명, 크기, MIME 타입, 저장 키)
• Approvals: 승인 단계별 행(누가, 무슨 결정, 언제)

관계를 엄격하게 유지하세요: 하나의 보고서가 여러 비용을 가지고, 하나의 비용은 여러 영수증 파일을 가질 수 있습니다(두 페이지짜리 영수증이나 수정본 업로드에 유용). 영수증 데이터를 비용 행에 직접 넣지 말고 사진은 파일로 보관하고 메타데이터와 포인터만 DB에 보관하세요.

영수증 사진은 기본적으로 비공개로 취급하세요. 비용에 접근 규칙을 저장해 직원, 지정 승인자 및 재무만 볼 수 있게 하세요.

‘누가 언제 무엇을 했는가’에 대한 감사 추적을 추가하세요. AppMaster에서는 PostgreSQL의 Data Designer에 submitted_by, approved_by, created_at, updated_at, decision_at 및 결정별 짧은 코멘트 같은 필드를 포함해 모델링할 수 있습니다.

반복 문의를 줄이는 승인 및 정책 검사

대부분의 지연은 누군가 비용을 제출하고 검토자가 세 번이나 질문해야 할 때 발생합니다. 해결책은 간단합니다: 규칙을 명확히 하고 직원이 제출 버튼을 누르는 순간 빠른 검사를 실행하세요.

모두가 이해할 몇 가지 정책 규칙으로 시작하세요. 직원이 나중에 놀라지 않게 규칙을 눈에 띄게 표시하세요. 대부분의 재작업을 막는 규칙 예시:

• 카테고리별 한도(예: 택시 한 건당 상한)
• 일일 식대 한도(아침·점심·저녁)
• 일정 금액 초과 시 영수증 필요
• 허용 날짜(미래 날짜 불가, 보통 X일 이상 지난 청구 불가)
• 중복 감지(같은 상점, 날짜, 금액)

이 검사들은 제출 시점에 실행하세요. 뭔가 빠졌다면 정확히 무엇을 고쳐야 하는지 알려주십시오. “금액이 $25 초과이면 영수증이 필요합니다”는 “유효성 검사 실패”보다 훨씬 낫습니다. 또한 음수 금액이나 통화 누락 같은 명백한 오류는 차단하세요.

모든 문제를 강제하지는 마세요. 예외인 경우 제출을 허용하되 명확히 표시해 검토 대상으로 만드세요. 예: 출장자는 호텔 영수증을 다음 날에야 받을 수 있습니다. 제출은 하되 “영수증 보류(Receipt pending)”로 표시하고 매니저 승인 후 재무로 라우팅하세요.

승인 라우팅은 회사의 자금 소유 구조와 일치해야 합니다. 어떤 팀은 직접 매니저만 필요하고, 어떤 팀은 큰 지출에 대해 코스트센터 소유자와 재무의 최종 확인이 필요합니다. AppMaster에서는 Business Process Editor에서 라우팅을 의사결정 흐름으로 모델링해 수동 추적 없이 올바른 경로를 따르게 할 수 있습니다.

도움이 되는 한 가지 세부사항: ‘메모와 함께 반려(Send back with note)’ 옵션을 포함하고 코멘트를 필수로 하세요. 이렇게 하면 대화가 이메일·채팅으로 흩어지지 않고 클레임 내부에 남습니다.

재무가 월말 마감 방식에 맞춘 내보내기

재무는 보통 “앱 보고서”를 원하지 않습니다. 그들이 이미 신뢰하는 월 마감 루틴에 맞는 파일, 즉 연결 가능한 깔끔한 컬럼과 합계를 원합니다.

매달 어떤 합계를 필요한지 합의하세요: 직원별, 카테고리별, 코스트센터별, 프로젝트별 등. 상세 라인과 요약을 모두 내보내어 재무가 스파이크를 감사할 수 있게 하세요.

내보내기 형식은 일부러 단순하게 유지하세요. 일관된 컬럼 이름의 CSV는 복사·붙여넣기 수정 작업을 줄여줍니다. 시간을 절약하는 컬럼 예시:

• Month (YYYY-MM)
• 직원 ID 또는 이메일
• 카테고리
• 코스트센터 및 프로젝트 코드
• 금액(원화), 통화, 금액(보고서 기준 환산)

다중 통화 처리는 내보내기가 흔히 깨지는 지점입니다. 제출 당시의 원래 금액과 통화를 정확히 저장하고, 보고용 환산 금액과 사용한 환율 및 환율 기준 날짜도 저장하세요(예: “영수증 날짜의 환율” vs “환급일의 환율”).

월말은 마감으로 취급하세요. 한 번 재무가 3월을 내보냈다면 3월은 바뀌지 않아야 합니다. 마감된 기간에 승인된 비용의 수정을 차단하는 월 잠금 기능을 추가하거나 다음 달에 정정 분개를 강제하세요. 간단한 마감 체크리스트:

• 모든 보류 승인 해결
• 내보내기 생성 및 저장
• 기간 잠금
• 늦은 영수증은 다음 달 조정으로 입력

AppMaster에서는 상태 필드, 기간에 대한 close 플래그, 월 잠금 시 편집을 차단하는 비즈니스 프로세스로 이 흐름을 깔끔하게 매핑할 수 있습니다.

지출 앱을 답답하게 만드는 흔한 실수

대부분의 지출 도구는 간단한 이유로 실패합니다: 사용자가 증빙을 빠르게 제출하지 못하고, 매니저가 다음 행동을 모르는 경우, 재무가 월말에 엉망인 데이터를 받는 경우입니다.

영수증 사진은 첫 번째 관문입니다. 어두운 레스토랑에서 찍은 영수증, 총액이 잘린 사진, 환율 정보가 없는 외화 영수증은 30초짜리 작업을 일주일간의 메시지로 바꿀 수 있습니다. 직원이 매니저가 볼 화면을 미리 확인할 수 있게 하고, 총액이나 날짜가 읽기 어려우면 재촬영을 요청하세요.

중복 제출은 두 번째 관문입니다. 흔한 패턴은 사용자가 휴대폰에서 제출한 뒤 제대로 됐는지 몰라 노트북에서 다시 제출하는 경우입니다. 복잡한 규칙 없이도 대부분의 중복은 merchant + date + amount 같은 간단한 매칭으로 표시하고 어떤 것을 남길지 사용자에게 확인하게 하세요.

승인 병목은 보통 소유권이 불명확해서 발생합니다. 비용이 방치되어 있으면 누군가가 승인 권한을 모르는 경우거나 작은 금액에 너무 많은 단계가 설정된 경우입니다.

피해야 할 실수(대안 포함)

• 카테고리가 너무 많은 경우: 짧은 목록(여행, 식대, 숙박, 주행비, 기타)으로 시작하고 재무에서 나중에 매핑하세요.
• 필수 필드가 너무 많은 경우: 정책상 정말 필요한 것(금액, 날짜, 상점, 영수증)만 요구하세요.
• 알림이 없는 경우: 2~3일 후 적절한 승인자에게 알림을 보내세요.
• 일괄 승인만 있는 경우: 저액은 자동 승인하고 필요한 경우에만 에스컬레이션하세요.
• 통화 표시가 불명확한 경우: 영수증별 통화를 저장하고 환산 근거를 표시하세요.

AppMaster로 구축하면 규칙을 워크플로우에 가시화해 정책이 바뀔 때 전체를 재구성하지 않고도 조정할 수 있습니다.

롤아웃 전에 빠르게 확인할 것들

전사 초대 전에 5~10명 규모의 짧은 파일럿을 수행하세요(빈번히 출장하는 직원 1명, 승인 빈도가 높은 매니저 1명, 재무 담당자 1명 포함). 목표는 기본 흐름이 빠르고 명확하며 쉽게 망가뜨리지 않는지 확인하는 것입니다.

타이밍 테스트로 많은 것을 알 수 있습니다. 직원이 정상적인 청구를 신속히 끝내지 못하면 영수증을 모아두고 서류 더미가 다시 생깁니다. 매니저가 회의 사이에 휴대폰으로 승인하지 못하면 승인 지연이 생깁니다.

롤아웃 준비 체크리스트:

• 직원이 1분 이내에 청구를 제출(영수증 1장, 팁 포함, 메모 선택사항)할 수 있다.
• 매니저가 휴대폰에서 30초 이내에 열어보고 승인할 수 있다.
• 모든 비용이 보고서에 묶여 있고 각 보고서에 명확한 승인자가 있다(고아 항목 없음).
• 재무가 한 번의 단계로 한 달 전체를 내보낼 수 있고 합계가 수작업 없이 일치한다.
• 영수증이 저장되고 검색 가능하며 항상 올바른 비용에 첨부된다.

현실적인 시나리오를 하나 끝까지 테스트하세요: “오늘 택시 영수증 제출 → 다음 날 승인 → 이 달 내 내보내기 포함.” 불분명한 부분이 있으면 화면 텍스트와 기본값을 수정한 뒤 기능을 추가하세요.

AppMaster로 구축한다면 파일럿을 속도와 명확성에 우선 집중하세요. 정책 검사를 나중에 추가할 수는 있지만 첫 경험이 느리면 회복하기 어렵습니다.

예시: 출장 하나, 영수증 세 장, 원활한 월말

Maya는 이틀짜리 고객 방문을 갑니다. 그녀는 가는 동안 앱으로 처리해 서류가 쌓이지 않습니다.

첫날 택시 영수증 $28과 호텔 청구서 $412를 업로드합니다. 앱이 사진에서 상점과 금액을 읽어오지만 스캔이 흐릴 경우 Maya가 빠르게 수정할 수 있습니다.

저녁에 영수증을 못 받은 식사는 $34로 수동 입력하고 “영수증 없음”으로 짧은 이유를 적습니다: “식당 영수증 프린터 고장, 카드 결제.” 흐름은 멈추지 않지만 문제가 숨겨지지 않습니다.

매니저 Jordan은 다음 날 보고서를 검토합니다. Jordan은 택시와 호텔은 한 번에 승인하고 식사 항목에는 “고객과 함께였나요? 이름 추가하세요.”라고 적어 정보를 요청합니다. Maya는 클레임 내에서 답하고 참석자를 추가한 뒤 Jordan이 승인합니다.

재무는 환급 전에 전체를 검토합니다. 재무는 그 도시의 식대 정책보다 $6 초과된 부분을 예외로 표시하지만 월말을 막지는 않습니다. 보고서는 환급되고 예외는 코칭 대상으로 추적됩니다.

월말에 재무는 마감 방식에 맞춘 합계를 내보냅니다. 실용적인 내보내기에는 보통 다음이 포함됩니다:

• 직원, 부서, 코스트센터
• 날짜, 상점, 카테고리
• 금액, 세금, 통화
• 영수증 상태(첨부됨, 없음, 판독불가)
• 승인 및 예외 플래그

월말은 “여행: $440”, “식대: $34”, “예외: 1”처럼 보이고, 감사가 요청하면 영수증 이미지에 접근할 수 있습니다. AppMaster로 구축하면 정책이 바뀔 때 워크플로우와 내보내기 필드를 쉽게 조정할 수 있습니다.

다음 단계: 파일럿, 측정, 그리고 쉽게 바꿀 수 있게 구축하기

작게 시작하세요. 파일럿 그룹은 충분히 실제 영수증을 생성해 흐름을 테스트할 수 있어야 하되, 수정 작업이 부담스러울 정도로 많지는 않아야 합니다.

파일럿에게는 한 페이지 분량의 요약을 제공해 일상적인 질문에 답하세요: 어떤 경우에 영수증이 필요한가, 어떤 경우 영수증 없이 허용되는가, 어떤 카테고리를 사용해야 하는가, 매니저는 얼마나 빨리 승인해야 하는가. 사용자가 10초 안에 규칙을 못 찾으면 추측하게 됩니다.

파일럿 설정 체크리스트:

• 서로 다른 역할과 지역에 걸쳐 10~30명 선택
• 명확한 시작일과 2~4주 테스트 기간 설정
• 누가 승인하고 누가 월말 합계를 내보낼지 정의
• 청구가 반려되면 어떻게 처리할지 결정(편집 후 재제출 또는 새 청구)
• 문제와 정책 질문을 보고할 하나의 공유 장소 만들기

파일럿 중에는 마찰을 보여주는 몇 가지 수치를 측정하세요:

• 제출까지 평균 소요 시간(앱 열기부터 제출까지)
• 승인까지 평균 시간(제출부터 매니저 결정까지)
• 예외율(영수증 누락, 잘못된 카테고리, 한도 초과)
• 재작업률(수정 요청으로 되돌아온 비율)

2~4주 후에는 데이터에 근거해 카테고리, 한도, 알림을 조정하세요. 식대가 가장 많은 예외를 만든다면 필요한 정보를 짧게 힌트로 추가하거나 “고객 식사”와 “팀 식사”로 분리하세요.

변경이 쉬운 구조로 만드세요. 지출 정책은 진화하고 팀은 성장하며 재무는 새로운 내보내기 필드를 요청할 것입니다. 빠르게 움직이고 싶다면 AppMaster는 백엔드, 웹, 모바일 전체 워크플로우를 빌드한 뒤 사용 중인 클라우드에 배포하거나 소스 코드를 내보낼 수 있게 해 줍니다. 요구사항이 바뀌면 로직을 업데이트하고 앱을 재생성하면 되므로 임시방편을 쌓지 않아도 됩니다.

앱 접근을 더 탐색하고 싶다면 appmaster.io는 노코드로 프로덕션급 앱을 빠르게 구축하려는 팀에 실용적인 출발점이 될 수 있습니다.