녹선 플랫폼 회계·경리 프로세스 검토 대화 기록

녹선 플랫폼의 프로세스 및 회계 처리 범위 검토

경리 업무 프로세스와 MVP 개발 프로세스의 비교 • 경리 업무는 세금계산서 확인 및 입력, 출금 처리에 국한되어 있으며 관리 포인트가 제한적이다. • 경리팀은 네이버 원장, 매출 원장 작성 및 입금 정리 업무만 수행하고 있다. • 현재 진행 중인 MVP 개발 프로세스는 경리 업무 프로세스와 동일한 구조를 가지고 있다. 원자재 구매부터 출하까지의 프로세스와 경리 업무 범위 • 원자재 구매, 단가 설정, 견적 작성, 수주, 생산 지시, 출하, 제품 검사 등의 단계로 구성된 전체 프로세스가 진행된다. • 경리 부서의 주요 업무는 구매 단계에서 세금계산서 발행을 담당하며, 발주는 별도의 담당자가 처리한다. 자재 발주 및 경리 프로세스의 역할 분담 • 자재 발주는 발주 담당자가 담당하고, 경리 담당자는 업체로부터 받은 세금계산서를 확인하여 처리한다. • 경리 담당자는 품의서를 통해 금액 지출에 대한 대표 승인을 받는 절차를 진행한다. • 단가 설정 후 견적서로 넘어가고, 견적서의 금액을 기반으로 수주 프로세스가 진행된다. 판매팀과 경리팀의 견적 금액 처리 역할 분담 • 판매팀 직원들은 금액 관련 세부사항을 잘 알지 못하므로, 경리팀이 미수금, 신용거래 여부 등 거래처 정보를 고려하여 견적 금액을 결정한다. • 경리팀은 거래처의 신용도와 미수금 상황을 파악하여 할인 적용 등 견적 금액 조정을 담당한다. • 이벤트 등의 특수 상황에서는 인정 제도를 통해 추가적인 금액 조정이 이루어진다. 출고 전 선입금 유도를 위한 할인 이벤트 및 신용 거래 구조 • 초기 도입 시 출고 전 입금 완료 시 7% 할인을 제공하는 이벤트를 진행했다. • 건설업체 특성상 입금이 즉시 이루어지지 않아 신용 거래 구조가 형성되었다. • 신규 업체의 경우 출하 전 또는 이전에 선입금을 요구하는 정책을 적용하고 있다. 견적에서 수주로 넘어가는 경리 프로세스 및 신용거래 관리 • 대부분의 거래가 신용거래로 이루어지며, 수주와 발주 시점에 특별한 선금 프로세스는 없다. • 경리 프로세스에서 견적이 수주로 넘어갈 때 금액 확인을 거쳐 거래 명세서와 세금계산서를 발행한다. • 수주 후 생산 및 출하 단계에서 신용등급 승인 개념이 적용된다. 신용 거래 관리 및 경리 프로세스 개선 방안 • 대부분의 거래가 신용 거래이기 때문에 신용등급이 낮은 고객의 경우 출하 중단, 생산 거부, 주문 거절 등의 조건을 적용하고 있다. • 현재 이러한 신용 관리 조건들이 구두로만 진행되어 의사소통 어려움이 발생하고 있다. • 이를 개선하기 위해 신용등급 시스템을 도입하여 경리 부서의 개입 범위를 명확히 구분하고자 한다. 고객 등급별 주문 처리 프로세스 자동화 시스템 구축 • A등급 고객은 수주에서 생산, 출고까지 자동으로 진행되도록 설정하여 신속한 처리를 가능하게 한다. • B등급 고객은 수주 및 생산 후 입금 확인을 거쳐야만 출고할 수 있도록 제한한다. • C등급 고객은 미수금이 과다하여 일정 수준의 입금이 이루어질 때까지 신규 주문을 받지 않도록 시스템에서 차단한다. • 판매팀이 주문을 받더라도 시스템 설정에 따라 자동으로 수주 생산 단계로 진행되지 않도록 하는 장치가 필요하다. 소규모 기업의 거래처 관리 및 회계 처리의 비체계성 • 현재 거래처와의 금전 거래가 구두로만 이루어지고 있어 관리 체계가 필요한 상황이다. • 대규모 기업과 달리 소규모 기업들은 자금 거래 관리가 체계적이지 못하고 지저분한 경향이 있다. • 거래처 관리가 직원들에 의해 이루어지면서 관리 감독이 제대로 되지 않는 문제가 발생한다. 거래처 관리를 위한 계약서 및 수주 문서 체계 구축 • 현재 계약서 대신 견적서, 발주서, 수주서 등의 문서로 거래처를 관리하고 있다. • 수주서 확정 전 단계에서 수주 계약서를 추가로 도입하여 거래 프로세스를 체계화할 계획이다. • 기존 계약 관리 방식에서 문서 체계를 명확히 구분함으로써 거래처 관리 효율성을 개선하고자 한다. 견적서와 수주 계약서의 기능 통합 방안 검토 • 견적서는 일반적으로 거래 면세표 기능으로 금액만 표시하는 경우가 많으나, 업체에서는 자세한 항목 정보를 요구하기도 한다. • 수주 계약서에 견적서의 금액 기능과 자재 리스트의 상세 항목 기능을 통합하여 운영하는 방안을 제안한다. 녹선 플랫폼의 견적서 기반 거래 프로세스 간소화 • 계약서 항목의 필요성을 검토한 결과, 거래가 왕복하지 않고 일방적으로 진행되므로 견적서만으로도 충분하다는 결론에 도달했다. • 현재 견적서에 거래 계산서, 세금 명세서, 거래 명세서를 통합하여 약식으로 처리하고 있으며, 모든 항목을 수작업으로 작성하고 있다. 거래 명세서 커스터마이징으로 프로세스 간소화 • 현재 거래 명세서의 내용이 부실하므로, 품목 리스트를 포함한 커스텀 형식으로 개선하면 추가 프로세스 없이 진행 가능하다. • 거래 명세서 발송 후 회신이나 서명을 받지 않으므로, 현재 형식으로 프로세스를 종료해도 문제없다. • 소주서 단계에서 프로세스를 마무리하며, 생선 지시와 출하 관련 추가 절차는 불필요하다. 판매 및 경리 프로세스에서의 세금계산서와 입금 확인 절차 • 판매 부서의 경리 업무는 견적된 건에 대해 세금계산서를 발행하고 입금 여부를 확인하는 것이 핵심이다. • 거래처로부터의 입금은 매출의 원천이 되며, 발주처가 세금계산서 발행 후 입금을 진행한다. • 발주서는 자재 구매 시에도 사용되는 용어이지만, 판매 거래에서는 발주처가 우리에게 발주를 요청하는 형태로 진행된다. 녹선 플랫폼의 거래처 분류 및 입금 프로세스 • 거래처는 입금과 매출을 모두 포함하는 혼합적 개념으로, 발주처 또는 매출처로 구분하여 관리한다. • 녹선 플랫폼은 계약금 없이 견적 기반으로 세금계산서를 발행하며, 해당 금액을 건별로 입금받는 방식을 운영한다. 외상 거래 월별 청구 및 매출·매입 원장 관리 • 5월 13일 주문 건에 해당하는 거래 명세표는 개별 거래를 기록하는 문서이다. • 외상 거래가 많은 경우 월별로 한 달치를 한꺼번에 청구하는 방식으로 처리된다. • 매출 원장과 매입 원장을 통해 거래 내용을 체계적으로 관리하고 기록한다. 매출 원장의 구조와 거래처별 판매 내역 관리 • 매출 원장은 판매 거래를 일자별 및 거래처별로 구분하여 기록하고 조회할 수 있도록 구성되어 있다. • 명보 에스티 등 특정 거래처와의 거래 내역은 월별로 정리되어 한 달 동안의 거래 목록을 확인할 수 있다. • 매출 원장에서는 판매 종류별로 거래 내용을 분류하여 관리하고 있다. 판매 리스트의 거래처별 주문 및 로트 단위 관리 체계 • 판매 리스트에서는 거래처별로 주문 건수, 금액, 거래 명세서 발송 여부를 확인할 수 있도록 구성되어 있다. • 판매 번호는 로트 번호로 기능하며, 회사는 로트 단위로 수주를 받는 구조이다. • 현재 시스템에는 로트 필드가 명확하게 구분되지 않아 관리상 혼동이 발생하고 있다. 로트 추적 시스템을 통한 제품 주문 관리 프로세스 • 견적 수주 단계에서 시작하여 로트 번호를 부여하고 이를 지속적으로 추적하는 구조로 운영되고 있다. • 로트 번호에는 제품 정보, 주문 접수 시기 등 제품에 대한 상세 정보가 포함되어 있다. • 현장별로 로트 단위의 주문을 관리하며, 한 현장에 여러 개의 로트가 존재할 수 있다. 녹선 플랫폼의 견적 주문 미사용으로 인한 판매 기록 프로세스 • 견적 주문 기능을 사용하지 않아 판매 완료 건에 대해서만 결과치를 입력하고 있으며, 수주 날짜와 거래처 정보를 기록한다. • 출하 시점이 견적 시점과 다를 수 있어 로또 번호 중복이 발생할 수 있는 구조이다. • 현장명은 시스템 상에 표시되지 않지만 메모 형식으로 별도 작성하여 관리되고 있다. 녹선 플랫폼의 로또 번호별·거래처별 회계 관리 체계 • 로또 번호 리스트는 수주한 순서대로 관리되며, 각 로또 번호별로 거래 내역을 추적할 수 있다. • 거래처별 관리를 통해 한 달 동안의 거래 현황을 파악할 수 있으며, 월말에 총 금액으로 정산된다. • 월말 원장은 거래 명세서 형태로 업체들에게 전송되며, 이는 원장과 거래 명세서의 모음으로 볼 수 있다. 거래 명세서와 세금계산서 금액 불일치 문제 • 거래 명세서 금액과 실제 입금액이 일치하지 않는 경우가 발생하며, 예를 들어 3,500만 원을 청구했으나 업체에서 2,000만 원만 송금하는 상황이 발생한다. • 세금계산서는 실제 입금액 기준으로 발행되어야 하는데, 이로 인해 청구액과 세금계산서 금액의 불일치 문제가 경리 업무에서 발생한다. • 이러한 부분 입금 상황에서 세금계산서 발행 기준과 회계 처리 방식에 대한 명확한 프로세스 정립이 필요하다. 녹선 플랫폼의 세금계산서 발행 관리 및 미수금 처리 • 1,500원의 미수금이 시스템에 기록되며, 세금계산서 발행 여부를 빨간색으로 표시하여 관리하고 있다. • 업체마다 세금계산서 발행 방식이 다르게 진행되는데, 일부는 건별 발행, 일부는 월별 일괄 발행을 요청하여 경리 업무에서 누락 위험이 발생한다. • 경리 담당자는 세금계산서 누락을 방지하기 위해 체계적인 관리 방안이 필요하다. 녹선 플랫폼의 회계 프로세스 및 노트 구성 체계 검토 • 경리 부서는 발주처에 월 1회 원장을 발행하며, 총 금액과 노트 번호를 함께 제공한다. • 노트는 현장별 주문 건으로 구성되어 있으며, 수주 로드와 원자재 로드 등 여러 종류의 로트를 포함한다. • 현재 시스템에서 노트와 BOM 기준 간의 연결 구조가 명확하지 않은 부분이 존재한다. 인정 제도에 따른 로트 추적 및 생산 프로세스 • 인정 제도 운영을 위해서는 반드시 로트 추적이 필요하며, 이는 원자재 입고부터 생산까지 전 과정에서 진행된다. • 원자재 수입 검사 시 원자재 로트를 기록하고, 각 수주 건별로 현장 단위의 로트 관리를 수행한다. • 생산 단계에서는 추적된 원자재 로트를 투입하여 제품을 생산한다. 원자재 투입 및 현장 조립 제품 인증 프로세스 • 원자재 로트를 투입하거나 미리 재고를 생산하는 경우 고 로트를 사용하여 자재를 관리한다. • 제품은 현장에서 조립되며, 조립 완료 후 인증 제품에는 인증 라벨을 부착하여 인증 여부를 표시한다. 제품 검사 및 로트 번호 관리 시스템 • 최종 제품 검사 시 인정 라벨을 붙일 때 제품 로트 번호가 함께 부여된다. • 원자재 로트는 단순한 형식으로 날짜와 순번으로 구성되며, 예를 들어 250 1202 03과 같은 방식으로 표기된다. • 수주 로트는 내부적으로 정한 규칙에 따라 KB 은행 경동 같은 고정 코드 뒤에 SSS, SW, WE 등의 추가 코드가 붙는 형태로 관리된다. 스크린 셔터 제품의 원단 재질별 분류 및 인정 시험 기준 • KSS01은 실리카 스크린 원단으로 만든 스크린 셔터이고, KWS01은 와이어 원단으로 만든 스크린 셔터로 원재료에 따라 구분된다. • KWS, KSS01, KWS01 등의 제품 분류는 인정 시험을 받기 위한 기준이 되며, 제품 개발 후 인정 시험을 통과해야 한다. 제품 사양 및 규격 정의를 통한 로트 관리 프로세스 • 제품 판매 시 구성품, 규격, 사양, 재질 등이 사전에 모두 정해져 있으며, 이에 따라 제품에 이름을 부여한다. • 정해진 사양으로 시험을 거친 후 축약된 영문 두 글자를 조합하여 제품명을 만들고 해당 로트에 포함시킨다. 2025년 7월 21일 세 번째 발주의 수주 로트 프로세스 설명 • 2025년 7월 21일에 세 번째로 발주받은 건은 수주 로트로 분류되며, 생산 루트와 원자재 로트 처리 방식이 동일하게 적용된다. • 제품 로트는 예를 들어 KDSS 수주 로트에서 총 20개 단위로 구성될 수 있으며, 셔터 한 세트를 개소 단위로 표현한다. 제품 코드 부여 및 관리 방식의 업체별 차이 • 셔터 설치 위치에 따라 두 개소에 설치되며, KD SS250721-03과 같은 형식의 제품 코드로 관리된다. • 20개소 발주 건의 경우 제품 노트에 01, 02 등의 번호를 순차적으로 부여하여 각 제품을 구분한다. • 제품 코드 부여 및 관리 방식은 업체마다 상이하게 운영되고 있다. 로또 관리 로직의 자체 개발 및 운영 프로세스 • 인정 제도에서 구체적인 로또 부여 방식을 명시하지 않아 자체적으로 로직을 개발하여 운영하고 있다. • 초기에는 비표준적인 방식으로 보일 수 있지만, 현재는 이 방법이 고착화되어 익숙하게 운영 중이다. • 로또가 발생하면 원자재 뒤에 모두 연결되는 방식으로 관리되고 있다. 제품 생산 루트와 셔터 제품 분류 설명 • 수주 후 생산 과정을 거쳐 제품 루트가 결정되며, 제품의 종류에 따라 다양한 분류 체계가 적용된다. • 스크린 셔터는 KSS 01(SS)로, 철제 셔터는 KQTS 01로 구분되어 각각의 재질과 특성이 정해져 있다. 케이스 공일 원자재 사양 및 로트 관리 프로세스 • 케이스 공일은 스크린 본체, 절거품 모터 등 구성품과 부자재가 사전에 정해져 있다. • 스크린은 실리카, 파이버, 와이어 등 다양한 종류가 있으며, 와이어의 경우 0.8t, 0.75t 등 두께 사양이 다르다. • 원자재 수입 시 각 사양에 해당하는 원자재에 로트를 부여하여 관리한다. 원자재 관리 시스템의 부품 명세 기록 방식 검토 • 현재 원자재 관리 시스템은 날짜 정보만 기록되어 있어 다소 불완전하지만, 수입 검사서를 통해 상세 사항을 확인할 수 있어 큰 문제가 되지 않는다. • 동일한 스크린 셔터 제품이라도 KSS01과 KSS02 모델에 따라 가이드레일의 형태와 부품이 달라질 수 있으므로 제품별 명세 관리가 필요하다. 제품 BOM 구성 및 경리 프로세스 역할 분담 • KSS 01 제품을 기준으로 제품군별 BOM(자재명세서) 작업을 구성하고 있으며, 이를 통해 생산 및 발주 프로세스를 체계화하고 있다. • 생산 및 발주 단계에서는 경리 부서가 개입하지 않으며, 자재 발주 담당자가 자재 원가를 관리한다. 녹선 플랫폼의 자재 원가 관리 및 판매 단가 결정 프로세스 • 자재 원가 변동을 추적하기 위해 전월 대비 당월 철판 가격 변동을 엑셀로 관리하고 보고하고 있다. • 경리 부서는 자재 원가가 반영된 판매 단가를 관리하며, 회계 부서는 넘겨받은 금액 값만 확인하는 역할을 수행한다. • 금액 결정 시 계약 단계에서 거래처의 신용도를 검토한 후 금액을 조정하는 방식으로 진행된다. 인정 및 비인정 제품 판매 시 원가 조정 필요성 • 입고 원가에 마진을 더하여 판매 단가를 결정하는 기본 프로세스가 있으며, 할인율 적용 등의 변수가 존재한다. • 경리 관점에서는 인정 제품과 비인정 제품을 판매할 때 원가를 조정해야 하는 경우가 발생한다. 인정 제품과 비인정 제품의 품질 보증 및 원가 관리 차이 • 인정 제품은 품질 보증 책임이 있어 제출된 설계도와 자재가 완전히 동일해야 하므로 공수가 많이 소요된다. • 비인정 제품은 인정 제도 범위 밖이므로 품질 보증 책임이 없어 저가 자재 사용과 저가 발주가 가능하다. 비인정 제품 대량 수주 시 단가 조정 전략 • 발주 건의 경우 인정 제품 단가를 적용할 수 없으며, 더 낮은 가격으로 책정해야 한다. • 대량 공사나 줄건 같은 경우에는 비인정 제품으로 수주하는 건들이 많다. • 비인정 제품을 수백 개 단위로 수주할 때 총 금액이 커지므로, 입찰 경쟁력을 높이기 위해 단가를 조정하는 경우가 있다. 공급업체별 단가 조정 및 단가표 관리 프로세스 • 판매 단가보다 공급업체의 구매 단가가 낮은 경우가 많아 단가 조정이 필요하다. • 특정 공급업체는 빈인정 제품만 취급하므로 일반 인정 제품과 다른 단가를 적용해야 한다. • 단가표를 공유하여 공급업체별로 상이한 단가를 관리했으며, 원래는 월 1회 주기로 업데이트했다. 공급업체별 스크린 단가 조정 및 가격 협상 현황 • 원래 스크린 단가는 17,000원으로 책정했으나, 주유비만 인하하고 나머지는 동결하기로 결정했다. • 경쟁사 정보를 근거로 일부 업체에서 15,000원으로의 인하를 요청하면서 가격 조정이 불가피해졌다. • 업체마다 요구 사항이 다르고 가격 비교 및 협상이 심해서 업체별 맞춤형 조정이 필요한 상황이다. 거래처 등록 및 회계 프로세스 적용 현황 논의 • 거래처별 처리 방식에 대한 논의가 있었으나, 거래처 등록 기능이 아직 회계 시스템으로 이관되지 않았다. • 거래처 등록이 현재 회계 분류로 되어 있어 회계 담당자에게 아직 넘어가지 않은 상태이다. • 논의된 사항들이 전달되었으나 실제 반영 여부는 확인이 필요하며, 일부 항목은 추후 진행하기로 결정되었다. 주류 거래처 관리 및 세금계산서 처리 방식의 차이 • 일반 거래처는 사업자등록증, 대표 주민등록증 등의 서류를 받아 리카운트에 입력하는 방식으로 관리된다. • 주류 거래의 경우 별도 서류 제출 없이 업체에서 발행한 세금계산서 목록만으로 회계 처리가 이루어진다. 회계 시스템의 거래처 자동 등록 및 관리 기능 비교 • 회계 시스템에서 목록을 수렴하면 거래처가 자동으로 등록되며, 세금계산서 작성 시 필요한 거래처명, 사업자 번호, 대표자명 등의 정보가 자동으로 포함된다. • 이 자동 등록 기능으로 인해 별도의 거래처 정보 입력이 불필요하여 업무 효율성이 높아진다. • 현재 시스템은 경동과 비교했을 때 거래처 관리 방식이 다르며, 경동은 거래처 관리의 다각화가 필요한 상황이다. 견적서 발행 및 세금계산서 처리 프로세스 검토 • 현재 판매 프로세스는 견적서 발행, 세금계산서 발행, 입금 수령의 단순한 구조로 이루어져 있다. • 미수금이 많이 발생하고 있으며, 이에 대한 관리 체계가 필요하지만 현재 구축되지 않은 상태이다. • 견적 수주 후 금액에 대한 세금계산서 발행 및 입금 처리가 판매 업무의 전부인 상황이다. 원가 계산 및 지출 항목 관리 프로세스 검토 • 마진 계산 시 원가에만 적용되며, 인건비는 별도로 포함되지 않는 현재의 회계 처리 방식이 운영되고 있다. • 항목별 인건비 분류는 현재 시행되지 않고 있으나, 대표의 성향에 따라 향후 변경될 가능성이 있다. • 원가 책정 관련 상세 내용은 USB에 저장된 시트에서 확인할 수 있다. 녹선 플랫폼의 자재별 단가 조정 및 원가 관리 프로세스 • 대표가 절곡판, 주자재, 부자재, 모터 등 자재별로 서로 다른 관리 시트를 통해 단가를 조정하고 있다. • 철판의 경우 소스와 EGI 입고가, kg당 단가, 마진을 입력하며, 판단가와 가공비(인건비)를 계산하는 방식으로 원가를 관리한다. • 면적당 가공비를 기준으로 면적과 가공비를 곱하여 최종 단가를 산출하며, 인건비 마진이 전체 가공비에 포함되어 있다. 녹선 플랫폼의 입고·가공비·마진 관리 및 단가 산정 방식 검토 • 현재 입고, 가공비, 마진을 개별적으로 입력하여 금액을 조정하는 방식으로 운영 중이다. • 기성 할당 시 일부 항목에는 인건비가 포함되고 일부에는 포함되지 않아 단가가 상이하게 나타난다. • 원자재 단가만으로도 가격이 반영되고 있으므로, 현재 시스템에서는 세부 단가 구현이 이루어지지 않은 것으로 보인다. 녹선 플랫폼의 입고 단가 및 판매 단가 관리 프로세스 • 입고 단가가 입력되면 산출된 금액이 판매 단가로 자동 설정되는 시스템으로 운영 중이다. • 현재 견적에 모든 요소가 반영되어 있으며, 판매 단가는 50,100원, 62,000원, 22,000원 등으로 설정되어 있다. • 경리 담당자가 필요시 판매 단가를 조절할 수 있으나, 이는 해당 건에만 영향을 미친다. 견적 입찰 시 단가 유지 및 할인 조정 프로세스 • 대표님은 견적 입찰 시 자재의 정해진 판매 단가는 변경하지 않고, 할인이나 마진 조정을 통해 최종 금액을 조정하는 방식을 적용한다. • 단가를 직접 변경하는 대신 판매 단가에서 할인을 적용하거나 마진을 조정하여 금액을 조절한다. • 기입장에서는 마진을 제외한 순수 금액을 파악해야 할인 범위를 명확히 할 수 있다. 녹선 플랫폼의 판매 및 구매 프로세스 구조 • 판매 관련 기능은 판매 입력, 판매 현황, 판매 조회로 구성되며, 판매 리스트를 통해 관리된다. • 구매 프로세스는 자재 구매 시 거래처 코드를 불러오고 부가세 적용 방식을 설정한 후 금액을 입력하는 방식으로 진행된다. • 메이 원장 작성 시 거래처 정보와 세금 처리를 포함하여 구매 거래를 기록한다. 녹선 플랫폼의 다중 작성자별 지출 결의 및 전자결제 프로세스 • 5130 시스템에서 전자결제를 운영 중이며, 부품과 제품 주문이 여러 담당자에 의해 분산되어 처리되고 있다. • 지출 결의서의 품목별 작성자가 상이하므로, 작성자별로 구매 금액을 구분하여 보고 및 출금 처리를 진행한다. 대규모 출금 결재 프로세스 및 회계 원장 관리 개선 • 큰 비용의 출금은 품의 단계를 거쳐 최종적으로 대표님의 결재를 받는 프로세스를 따른다. • 경리는 중간 승인자로서 품의에서 올라온 항목을 메인 원장 형식으로 변환하여 관리할 필요가 있다. • 직원이 초기 입력 시에는 거래처 코드 없이 파일 첨부와 금액만 기입하지만, 경리의 검토 및 승인 단계에서 상세 정보가 추가되어야 한다. 녹선 플랫폼 회계 프로세스의 거래처 코드 및 부가세 설정 • 거래처 코드, 부가세, 지출 날짜 등 회계 거래에 필요한 세부 정보를 입력 단계에서 설정해야 한다. • 품에서 작성된 내용은 격리 단계에서 검증 및 확인을 거친 후 지출 예상 내역서로 등록되는 프로세스로 진행된다. 녹선 플랫폼의 월별 대규모 지출 승인 및 보고 프로세스 • 대표는 품의서로 사전 승인을 받은 후에도 최종 금액 집행 직전에 대규모 지출 내역을 재확인하는 절차를 거친다. • 월별 전체 지출 금액에 대해 품의 부서와 경리 부서가 작성한 내용이 모두 시스템에 통합되어 관리된다. • 전자결제 요청 기능을 통해 금액 및 관련 정보가 체계적으로 기록되고 처리된다. 거래처 등록 시 지급 일정 및 결제 조건 자동 반영 프로세스 • 거래처 정보 입력 시 지급 예정일(말일, 10일 등)을 미리 설정하여 수동 작업을 줄일 수 있다. • 자사가 받는 금액과 지급하는 금액의 결제 조건을 거래처별로 등록하면 시스템에 자동으로 반영된다. • 이러한 설정을 통해 품의서 작성 시 거래처별 금액이 자동으로 계산되어 회계 처리 효율성이 향상된다. 녹선 플랫폼의 지출 결의 및 거래 건별 통합 처리 방식 • 동일한 판매처에서 여러 건의 구매가 발생할 경우, 지출 결의 예상 내역서에서는 개별 건이 아닌 월별로 통합된 금액으로 표시된다. • 세부 내역은 확인 가능하지만, 실제 결제는 월별로 통합된 금액이 한 번에 처리되는 구조이다. • 지출 계획 단계에서 지출 예상 내역서를 거쳐 지출 결의서로 진행되며, 지출 결의서는 이미 결제가 완료된 상태를 나타낸다. 법인카드 결제 및 지출 결의서 승인 프로세스 • 법인카드 사용 내역은 10만 원 이상인 경우에만 영수증을 첨부하여 보고하며, 10만 원 미만은 생략된다. • 품의서와 지출 결의서는 직원이 작성하여 올리는 문서이며, 경리의 중간 검토를 거쳐 최종적으로 대표가 승인한다. • 카드 결제 내역 관리와 지출 결의 프로세스는 별도로 운영되는 회계 처리 체계이다. 녹선 플랫폼의 회계 거래 내역 조회 및 송금 확인 기능 필요성 • 경리 담당자는 한 달 동안의 모든 송금 내역을 한눈에 확인할 수 있고 이전 거래 기록도 조회할 수 있는 기능이 필요하다. • 출금 여부를 확인할 수 있는 기능이 추가되어야 송금 프로세스의 투명성이 높아진다. • 거래처별 미수금 현황과 채무 내역을 체계적으로 관리하고 확인할 수 있는 기능이 필수적이다. • 지출과 수입 항목 중 대부분은 자동 처리되지만 일부 항목에 대한 수동 확인 프로세스가 여전히 필요하다. 입금 보고서 기능과 금전 출납부 자동 연동 프로세스 • 현재 금전 출납부에서 모든 입금 내역을 수동으로 입력하고 있으며, 이 과정이 매우 불편한 상황이다. • 메인 원장의 입금 보고서 기능을 통해 입금액, 계좌 코드, 계좌명 등의 정보를 저장할 수 있다. • 입금 보고서에 저장된 데이터가 금전 출납부에 자동으로 표시되도록 연동하면 수동 입력 작업을 줄일 수 있다. 일일 재무 현황 보고 및 자동화 프로세스 개선 • 정미영 차장이 매일 입금 및 지출 내역을 대표님께 보고하며, 어음의 만기일과 남은 기간 등의 정보도 함께 전달한다. • 현재는 수기로 작성되고 있는 일일 보고 프로세스를 메이 원장 자동화를 통해 개선할 계획이다. 금전출납부 시스템의 예금 거래 및 어음 관리 기능 • 금전출납부 시스템은 예금 입출금 내역을 자동으로 표시하며, 출금과 입금 내역을 구분하여 관리한다. • 어음 관리 기능이 금전출납부에 통합되어 있어 어음 등록, 배서 일자 선택 등의 작업을 수행할 수 있다. • 시스템은 자동 표시 기능을 제공하므로 사용자의 추가 작업이 최소화된다. 어음 관리 및 전자 어음 시스템 프로세스 검토 • 거래처에서 현금 대신 어음을 발행하며, 이 어음은 다른 거래처에 양도하거나 사용할 수 있다. • 전자 어음 시스템이 연결되어 있으며, 거래처 관리 화면에서 돈을 받아야 할 거래처 목록을 확인할 수 있다. • 현재 사용 중인 전자 어음 프로그램의 구체적인 명칭과 기능에 대해 추가 확인이 필요하다. 금전 출납부의 전자 어음 처리 프로세스 • 금전 출납부에서 전자 어음을 발행할 때 발행자를 선택하고 배송 날짜, 만기일, 금액 등의 정보를 입력하여 저장한다. • 저장된 전자 어음은 만기가 될 때까지 계속 표시되며, 만기 전에 자금이 입금되는 연기 프로세스가 진행된다. • 만기일이 지나면 전자 어음은 결제 처리되어 시스템에서 제거된다. 미수금 관리 및 회계 카운터 시스템 프로세스 검토 • 미수금이 많이 쌓이면 악성 채권으로 분류되며, 현재 5130 카운터로 시스템이 구현되어 있다. • 판매 부서와의 연결을 위해 카운터 방식이 도입되었으며, 사용자 인터페이스 관점에서 더 편리한 것으로 평가된다. • 경리 담당자들은 두 가지 방식 모두 사용 가능하지만, 5130 카운터로 빠르게 통합하는 것이 효율적일 것으로 판단된다. 회계 관리 시스템의 주요 기능 및 품목 등록 목적 • 노션에 캡처된 화면들은 판매, 구매, 거래처, 채권, 채무, 입금, 지출, 세금계산서 등 회계 관리의 핵심 기능들을 포함한다. • 판매 리스트, 품목 등록, 거래처 등록, 거래처별 거래 내역 및 채무 현황 추적이 주요 관리 항목이다. • 품목 등록은 품목 관리 차원이 아니라 데이터 입력을 간편하게 하기 위한 실용적 목적으로 운영된다. 녹선 플랫폼의 회계 관리 메뉴 구성 및 격리 처리 검토 • MBP에서 이미 격리 처리가 되어 있어 별도의 추가 격리 작업이 필요하지 않다. • 기존 회계 관리 메뉴는 매출 관리, 매입 관리, 원가 관리, 재무제표로 구성되어 있다. 전자세금계산서 개발 및 장부 조회 기능 논의 • 전자세금계산서 개발이 진행 중이며, 매입 관리와 매입 원장은 동일한 개념으로 취급된다. • 장부 조회 항목에는 총 계정 원장, 메인 매출장, 현금출납장 등의 자금 관련 기능이 포함된다. • 매출과 판매, 구매 관련 메인 개념들이 통합되어 관리되는 구조로 설계되고 있다. 회계 카운트 내용 검토 및 AI 자동 생성 항목 확인 • 현재 카운트 내용에 필요한 모든 항목이 포함되어 있는지 확인하고 있으며, 일부 항목은 AI가 자동으로 생성하여 목록을 작성했다. • 판매 관련 항목을 검토 중이나 판매 쪽 항목이 누락되어 있는 상태이다. 회계 장부의 매출·매입·입출금 전표 구분 • 매출 전표는 판매한 거래를, 매입 전표는 구매한 거래를 기록한다. • 입금 전표는 수금된 금액을, 출금 전표는 지불한 금액을 나타낸다. • 이러한 전표들은 회계 장부 메뉴에 포함되어 있으며 거래의 성격에 따라 분류된다. 원장 조회와 전표 조회의 개념 및 로트 번호별 판매 관리 • 전표 조회는 원장 조회와 동일한 개념이며, 매출 원장, 매입 원장, 입금 원장, 출금 원장 등으로 분류된다. • 판매 데이터는 로트 번호별로 별도로 관리되어 다른 원장 조회와 구분된다. 녹선 플랫폼 회계 관리 화면 구조 개선 논의 • 매출, 매입, 입출금 세 가지 항목을 별도의 리스트 화면으로 분리하여 관리할 필요가 있다. • 세금계산서 진행 단계 기능이 현재 시스템에 포함되어 있으며, 이에 대한 추가 검토가 필요하다. 세금계산서 발송 관리 및 장부 조회 기능 개선 논의 • 현재 진행 단계 표시보다는 세금계산서 발송 여부를 확인할 수 있는 관리 화면이 필요하다. • 세금계산서 발송 상태를 '했다', '안 했다'로 명확하게 구분하여 관리할 수 있는 기능이 요구된다. • 매입 전표와 매출 전표 등 장부 조회 기능의 개선이 논의되었다. 회계 플랫폼의 입출금 전표 및 원장 관리 구조 검토 • 입금 전표와 출금 전표 입력은 신규 데이터 입력 기능이며, 이를 관리하는 원장이 하단에 위치한다. • 거래처 원장 리스트와 계정별 원장은 입력된 값을 조회하고 표시하는 기능으로, 필요에 따라 두 가지 모두 제공되어야 한다. • 계정은 입금, 미수금 등의 거래 유형을 분류하는 항목으로 정의된다. 법인 카드 계정 관리 및 경리 시스템 개념 부재 • 법인 카드 사용 시 여러 계정으로 자동 분배되어야 하는데, 현재 시스템에서 항목 관리 기능이 있는 것으로 보인다. • 비과세 등의 카테고리가 존재하지만 현재 운영 중인 플랫폼에서는 이러한 기능을 활용하지 않고 있다. • 경리 담당자들이 계정 개념에 대한 이해가 부족하여, 계정 관리 체계가 제대로 정립되지 않은 상태이다. 녹선 플랫폼의 회계 관리 및 필수 장부 검토 • 현재 계정 관련 관리가 전혀 이루어지지 않고 있으며, 대표가 이를 개선하고자 한다. • 매출장과 현금 출납장이 필수적으로 필요하며, 입력 데이터가 자동으로 연동되는 구조이다. • 금전 출납부와 자금 관리를 위해 현금 출납장의 거래 기록이 우선적으로 확인되어야 한다. 재무상태표와 부가세 신고 프로세스 검토 • 재무상태표가 회계 관리에 필수적인 문서로 확인되었으며, 거래처 관리와 함께 필요한 항목이다. • 부가세 신고는 거래 관련 정보를 기반으로 처리되고 있다. • 감가상각 관리는 현재 장비 관리가 이루어지지 않고 있으나, 향후 필요에 따라 진행할 예정이다. 카드 및 계좌 등록을 통한 입출금 자동화 프로세스 검토 • 개발팀 팀장과 협의하여 카드 등록 및 계좌 등록 관련 사항을 확인해야 한다. • 현재 수동으로 처리 중인 입출금을 자동화하기 위해 하루에 한 번 데이터를 가져와 정리하는 방식을 검토 중이다. • 입출금 자동화 프로세스는 개발팀 팀장도 인지하고 있는 사항이다. 회계 프로세스 메뉴 통합 및 보고서 정리 논의 • 현재 입금 보고서, 지출 결의서, 전자결제 경영 융합 보고서 등 약 5개 메뉴가 있으며, 이들을 기능별로 통합할 수 있을 것으로 판단된다. • 유출구 계좌 조회 기능이 필요하며, 대표가 원하는 수준에 맞춰 보고서 항목을 정리할 예정이다. • 메뉴 통합 작업을 빠르게 진행하기 위해 추가 논의를 통해 최종 정리를 진행하기로 결정했다. 회계 부서 필요 항목 검토 및 매출 전표 작업 • 회계 부서에서 요청한 필수 항목들을 노란색으로 표시하여 관리 중이며, 매출 전표와 관련된 모든 데이터가 필요하다. • 현재 진행 중인 작업에서 필요한 모든 항목을 완벽하게 포함시켜야 하는 상황이다. 녹선 플랫폼의 매출·매입·입출금 회계 프로세스 검토 • 회계 시스템에는 매출, 매입, 입금, 출금 항목이 필수적으로 포함되어야 한다. • 매출 매입 장표는 실제 사용 중인 항목들을 체크하고 검증하는 과정을 거친다. • 매출 원장과 출입력 등 용어는 다를 수 있지만, 매출 거래 입력 기능은 필수적으로 구현되어야 한다. 매출 원장과 입금 출금 전표의 회계 처리 방식 • 매출은 판매 시 자동으로 시스템에 입력되며, 카운트 기준으로 매출 원장을 조회할 수 있다. • 입금 전표는 실제 입금된 거래를 기록하고, 출금 전표는 단순 입력 형태로 처리된다. 세금계산서 자동 연동 시 회계 프로세스 정리 필요 • 전체 거래 조회 표와 개별 거래 항목을 구분하여 관리하며, 세금계산서 발행 여부만 체크하면 된다. • 세금계산서가 전표와 자동으로 연동되는 순간부터는 내부 관련 사항이 명확하게 정리되어야 하며, 그렇지 않으면 재작업이 발생한다. • 세금계산서 처리는 단순 발행 여부 확인을 넘어 전체 프로세스가 포함되어야 하므로, 필요 없으면 처음부터 제외하는 것이 효율적이다. 회계 시스템 구현 시 영수증 및 세금계산서 처리의 복잡성 • 영수증, 청구서, 세금계산서 등 다양한 문서 유형을 모두 고려하여 회계 시스템에 입력해야 하며, 입력 오류 시 수정 프로세스도 함께 설계되어야 한다. • 단순한 클릭 버튼 기능만으로는 부족하며, 실제 회계 계정에서 수행해야 할 작업들에 대한 충분한 검토와 고민이 필요하다. • 현재 다중 비용을 빠르게 적용하려는 접근이 시스템의 복잡성을 과소평가하고 있다는 우려가 제기되었다. 회계 시스템의 분개장과 거래처 관리 프로세스 검토 • 분개장은 전표와 매입·매출 관련 내역을 기록하는 리스트로, 별도의 기능 없이 항목으로만 구분된다. • 거래처 관리는 판매 부서에서만 처리되며, 매입 거래와 매출 거래를 분리하여 관리한다. 녹선 플랫폼의 거래처 관리 및 회계 정보 입력 프로세스 검토 • 경리 시스템에서는 판매팀이 입력한 사업자 등록번호, 대표자 정보, 신용 등급 등의 거래처 정보를 관리해야 한다. • 판매팀에서 사업자 등록증을 직접 입력할 수 있는 수준의 정보와 회계팀에서만 처리해야 하는 정보 간의 구분이 필요하다. • 거래처 관리 프로세스에서 정보 입력의 범위와 수준을 명확히 정의하는 것이 중요하다. 거래처별 판매 내역 및 계정 관리 프로세스 논의 • 거래처별 판매 내역 조회가 필요하며, 현재 계정 관리 체계가 구축되어 있지 않은 상태이다. • 지출 발생 시 계정으로 분리하여 세금 처리 방식을 결정해야 할 필요성이 제기되었다. • 계정 관리 도입 시 계좌 관리 시스템을 통해 이러한 기능 구현이 가능할 것으로 예상된다. 자금 일보 입력 프로세스 정리 및 확인 필요 • 현금 출납과 자금 일보 보고서의 계정 색깔 구분 및 표시 방식을 내일 확인할 필요가 있다. • 자금 일보의 입력 프로세스가 정리되어야 정확한 보고서 작성이 가능하며, 매일 입력하는 방식에 따라 결과가 달라질 수 있다. 일일 자금 현황 보고 및 전표 입력 프로세스 • 자금 현황 보고는 작성 기준일 기준으로 어제까지의 계좌 입출금 내역을 정리하는 방식으로 진행된다. • 수입은 수금 전표로, 지출은 지출 전표로 구분하여 매일 입력하며, 작성된 내용은 다음 날 보고되어야 한다. 거래처 관리 및 회계 프로세스의 수기 작업 개선 필요 • 현재 거래처별 재무 제어와 금액 합산 작업이 수기로 진행되고 있어 효율성 개선이 필요하다. • 거래처 관리 대장을 통해 매출액, 미수금, 미납금 등을 통합적으로 관리할 수 있는 시스템 구축이 요구된다. • 회계 부서에서 별도의 거래 관리 기능이 필요하며, 이는 거래처별 금액 현황을 체계적으로 추적하는 역할을 한다. 거래처 관리 기능 통합 및 메인 키 정렬 • 거래처 관리 메뉴는 여러 항목으로 분산되어 있지만, 기능은 하나로 통합하여 별도 관리를 피해야 한다. • 거래처 관리의 메인 키가 다른 시스템에서 이미 처리되고 있으므로, 현재 시스템은 이에 맞춰 설정하면 된다. 재무상태표 관리 및 분기별 매출 보고 프로세스 • 정미영 차장이 현재 재무상태표 작성을 담당하고 있으며, 이 업무는 복잡한 정책 수립이 필요하다. • 분기별 및 월별 주요 매출을 정리한 엑셀 파일이 존재하며, 이를 대표에게 보고하는 방식으로 운영되고 있다. 엑셀 기반 보고서 작성 및 프로그램 이전 시 복잡성 논의 • 현재 엑셀로 작성 중인 보고서는 수식과 수직 기능을 포함하고 있으나, 프로그램 이전 시 복잡성이 증가할 수 있다. • 보고서의 서식은 상대적으로 간단하며, 필요한 계산이 완료되면 총금액 수준의 결과를 도출할 수 있을 것으로 예상된다. 회계 처리 및 감가상각 방식 검토 • 대차대조표는 회계사 수준이 아닌 기본적인 수준으로 작성하기로 결정했다. • 장비 보유로 인해 감가상각 처리를 향후 적용할 계획이다. • 현재 경동에서 감가상각을 사용하지 않고 있으며, 향후 경동 방식으로 전환하기로 했다. 재무상태표 작성 시 감가상각 처리 및 카드 사용 내역 관리 방안 • 재무상태표 작성 시 감가상각을 분기별로 처리하여 정확성을 높이며, 추가 자료 확보 시 더욱 정밀한 재무 현황 파악이 가능하다. • 카드 사용 내역 등록 시스템을 단계적으로 구축하여 현재는 기본 등록만 진행하고, 향후 사용 내역을 반영하는 방식으로 운영할 계획이다. • 개별 거래 항목(예: 20원, 5천 원 등)의 입력 과정을 간소화하여 업무 효율성을 개선해야 한다. 제조업 시스템의 필수 항목 제외 및 카드 계좌 등록 프로세스 • 제조업 기업의 회계 시스템에서는 회계, 인사 등 필수 항목을 제외하고 사용자 정의 항목만 수정 가능하도록 설계되어 있다. • 카드 계좌 등록은 업체마다 다르게 처리되며, 5,000원 지출 같은 거래 내역을 텍스트로 입력할 수 있는 유연성을 제공한다. 업체별 계좌 등록 및 관리 포인트의 다양성 • 카드 계좌 등록 시 업체마다 관리하는 포인트가 다르며, 계좌의 용도에 따라 등록 방식이 달라진다. • 기업들은 계좌 등록 후 사람, 팀과의 매핑, 데이터 추출 등 다양한 니즈를 요구하며, 이러한 맞춤형 요구사항을 충족시킬 수 있다. MVP 개발 시 필수 항목과 선택 항목 구분 논의 • 모든 회사에서 동일하게 사용하는 표준 항목은 기존 솔루션을 활용하고, 변경이 필요한 항목만 자체 프로그램으로 개발하는 방식을 제안한다. • MVP 단계에서는 반드시 포함되어야 하는 필수 항목과 선택 항목을 명확히 구분하여 개발 효율성을 높일 필요가 있다. 녹선 플랫폼 회계 관리 기능 구현 방식 논의 • 해당 항목은 대메뉴 형태가 아닌 팝업이나 소규모 입력 창 형태로 기능을 통합하여 관리할 필요가 있다. • 현재는 입력 형태로 구현하되, MVP 이후에는 외부 시스템과 연결하는 형태로 확장할 계획이다. • 사용자가 나중에 정보를 잊지 않도록 하기 위해 실제 사용 가능한 형태의 기능 구현이 필수적이다. 카드 등록 기능의 필요성에 대한 재검토 • 카드 기능 구현은 카드 입력 칸, 카드 번호, 은행 정보 등을 입력받고 이를 사용자와 연결하는 일련의 프로세스를 포함한다. • 각 업체마다 요구사항에 맞춘 맞춤형 기능 제공이 핵심 포인트이다. • 현재 검토 결과, 카드 및 계좌 등록 기능이 반드시 필요하지 않다고 판단된다. MVP 1차 개발 범위 및 우선순위 결정 • 1차 MVP 개발 시 필수 기능을 먼저 구현하고, 추가 기능은 나중에 필요에 따라 개발할 수 있도록 계획한다. • 개발 우선순위는 두 가지 파트로 나뉘며, 먼저 핵심 기능(호어)을 완성한 후 대표가 원하는 형태의 MVP를 구성한다. 1월 오픈 이후 우선순위 기반 기능 개발 및 수기 처리 방식 논의 • 현재 인력 부족으로 인해 1월 오픈 시점까지 제한된 범위 내에서만 작업을 진행하고, 이후 우선순위에 따라 필요한 기능을 지속적으로 추가할 계획이다. • 출금 거래의 계좌 추적 등 일부 기능은 수기로 처리하기로 결정했으며, 이는 계정 관리 시스템과 연계된다. 회계 시스템에서 계정과 계좌 구분 및 입출금 관리 • 회계 관리에서 사용하는 계정은 돈의 종류를 분류하는 개념으로, 은행 계좌나 카드 계정과는 다르다. • 입출금 기록 관리 시 계좌 잔액 표시와 카드 정보 자동 입력 기능을 통해 효율적인 거래 추적이 가능하다. • 법인카드 종류별로 구분하여 관리할 수 있으며, 전자결제 시 카드 정보가 자동으로 연동된다. 여러 계좌의 자금 통합 및 회계 관리 프로세스 • 500만 원과 200만 원을 각각 보유한 여러 계좌의 자금을 합산하여 700만 원으로 통합 관리해야 한다. • 계좌별로 자금을 분류하면 나중에 보고서 작성 시 부서별 지출 현황을 파악하기 용이하다. • 계정 관리 시스템에는 카드, 현금, 은행 계좌 등 모든 자금 관리 수단이 포함되어야 한다. 회계 시스템의 계정 관리 및 거래 원장 구성 요소 논의 • 계정 관리는 회계 용어로서 세분화된 항목들로 구성되어 있으며, 경리 담당자들이 이해하는 개념이다. • 거래 원장 작성을 위해서는 거래 기록뿐만 아니라 매출 관리 등 필요한 항목들이 포함되어야 한다. • 전표 입금 처리 시 카드 정보 등 필수 요소들이 시스템에 포함되어야 거래 원장이 완성된다. 카드 구분 및 기초 정보 등록 방식 결정 • 카드 구분은 필수적으로 포함되어야 하며, 기능별 카드는 메뉴가 아닌 기초 정보 입력 영역으로 분류된다. • 기초 정보 등록 섹션에 카드 정보를 입력하고 한국어로 표기하기로 결정했다. 출금 계좌 조회 자동화 및 은행 API 연동 검토 • 현재 출금 계좌 조회 기능은 자동화되지 않아 수기로 처리하고 있으며, 계좌 입력 시스템과 연결되어 있다. • 자동 출금 처리를 위해서는 은행 API 연동이 필요하며, 보건 실장이 이에 대한 방안을 검토 중이다. • 은행에서 제공하는 API를 활용하여 연결하면 향후 자동으로 금액 표시가 가능할 것으로 예상된다. 녹선 플랫폼 회계 프로세스의 은행 연동 및 과거 내역 관리 방안 • 현재 플러스 마이너스 계산으로 산출된 금액과 실제 금액을 대조하는 방식을 사용하고 있으며, 두 금액이 일치해야 한다. • 정확한 회계 처리를 위해서는 단순 계산 방식이 아닌 은행 연동이 필수적이다. • 과거 30년치 거래 내역을 시스템에 반영하는 방법에 대한 기술적 검토가 필요하다. 녹선 플랫폼의 회계 프로세스 및 문서 정리 논의 • 실시간 운동 금액 수령 시스템과 이전 스토리 부재로 인한 모호함을 정리할 필요가 있다. • 카드 매입 조회는 현재 입력 상태이므로 조회만 진행하면 되며, 입금 보고서와 지출 결의서는 전자결제 방식으로 처리된다. • 입금 보고서는 내입 원장 작성과 유사한 부분이 있으나 주요 항목은 아니다. 입금 전표와 입금 보고서의 기능 및 용어 구분 • 입금 전표와 입금 보고서는 유사한 기능을 하지만 용어와 명칭이 혼동되고 있다. • 현재 시스템에서는 지출 예상 내역서로 운영 중이며, 미수금 추적 등의 기능을 포함하고 있다. • 입금 보고서라는 명칭이 있지만 실제 기능은 입금 전표에 해당한다. 녹선 플랫폼 회계 프로세스의 미수금 및 급여 관리 기능 검토 • 현재 보고서에는 미수금 권리 관리 기능이 없으며, 이는 제거해도 될 것으로 판단된다. • 채권 추심 및 인사 관련 회계 기능이 부재하여 추가 개선이 필요하다. • 급여 및 퇴직금 관리 기능이 필요하며, 경동에서 사용하는 승인 프로세스도 검토 대상이다. 전자결제 프로세스에서 품의서 및 지출 결의서 승인 절차 검토 • 전자결제 단계에서 품의서와 지출 결의서 제출 시 견적 단계에서 금액 조정 후 승인하는 프로세스를 확인해야 한다. • 현재 논의된 여러 항목들을 정리하여 전자결제 단계에서 다루어야 할 주요 문서들을 결정할 필요가 있다. 녹선 플랫폼 회계 프로세스의 지출 결의서 및 원장 관리 • 지출 결의서와 품의서는 필수 문서이며, 경리 담당자가 별도로 생성하여 관리해야 한다. • 월별 거래 명세서는 원장 형식으로 정리되어 월별로 거래처에 발송되는 형태로 출력되어야 한다. • 개별 거래 건들을 모아 전표 형식으로 정리한 후 원장식으로 통합 관리하는 프로세스가 필요하다. 거래명세서 문서 형식 및 월별 회계 처리 방식 검토 • 월별 회계 처리는 직접 입력 방식이 아니라 모아서 보여주는 형태로 진행된다. • 업체에 보내기 위해서는 거래명세서 같은 공식 문서 형식이 필요하다. • 현재 만들어진 거래명세서 문서가 건별로 모든 항목을 포함하고 있는지 확인이 필요하다. 녹선 플랫폼 회계 문서 및 급여 관리 프로세스 정리 • 현재 검토 중인 문서는 지출 결의서, 소계서, 거래 명세서 등 회계 관련 서류이다. • 인사 부서에서는 연차 신청서 외에도 급여 대장 작성이 필수적으로 필요하다. • 기존에 유사한 양식이 있었으므로 이를 확인한 후 진행하기로 결정했다. 급여 명세서 시스템 구축 방식 검토 • 급여 명세서는 직원별로 배포되는 문서로, 현재 시스템 규모가 상당하다. • 급여 처리 과정에서 세무서나 노무사에 대한 의존도가 높으며, 오류 발생을 방지하기 위해 시스템을 제대로 구축하거나 외부 의존도가 높은 쪽에서 결과만 받아 표시하는 방식을 고려 중이다. 급여 처리 및 경리 프로세스 외부 솔루션 활용 방안 • 현재 경리 부서는 기본급 등의 정보를 입력한 후 노무사에게 전달하여 보험금 등을 계산하는 방식으로 운영 중이다. • 외부 솔루션을 활용하여 급여 관련 데이터를 직접 받아오는 방식의 도입을 검토하고 있으며, 내일 회의에서 대표와 구체적인 방안을 논의할 예정이다. 회계 프로세스에서 수동 입력과 자동 계산의 혼합 운영 • 회계 카운트에 데이터를 수동으로 입력하는 방식을 사용하며, 자동 계산 기능만으로는 모든 항목을 처리할 수 없다. • 지난달 데이터는 그대로 가져올 수 있지만, 변수가 발생한 항목들은 별도로 수정하는 추가 작업이 필요하다. 노무사 의존도 감소를 위한 급여 처리 프로세스 개선 • 현재 회계·경리 프로세스에서 노무사의 의존도가 높으며, 이를 줄이기 위해 자동화된 시스템 구축이 필요하다. • 노무사로부터 엑셀이나 폼 형식으로 데이터를 받아 직접 업로드하는 방식으로 전환하면 프로세스 효율성을 개선할 수 있다. • 급여 처리 시스템에 입력 기능을 최소화하고 자동 처리 방식을 도입하는 것이 가장 깔끔한 구현 방법이다. 급여 명세서 항목 입력 및 사원 관리 프로세스 • 급여 명세서는 모든 항목이 자동으로 계산되어 나오므로, 해당 값들을 입력 양식에 기입하는 방식으로 운영된다. • 급여 관리 시스템에서 사원 등록 후 사원별 급여 지급 사항 탭을 통해 급여, 식대, 사용, 유지비 등의 항목을 입력하도록 구성되어 있다. • 계산 누락을 방지하기 위해 모든 항목을 빠짐없이 입력해야 하며, 항목이 많을수록 더 많은 데이터 기입이 필요하다. 급여 계산 프로세스 및 급여 테이블 관리 방식 • 기본급은 70% 비율로 책정되며, 10대 차주 기준 월 220만 원씩 책정되어 있다. • 직무 연장 수당 등 추가 수당은 별도의 계산 비율이 적용되며, 급여 테이블은 회사마다 다르게 구성된다. • 매월 신규 버튼을 통해 전월 급여를 기반으로 다음 달 급여를 생성한 후, 세금 등 필요한 항목을 조정하여 확정한다. 엑셀 입력 프로세스 자동화 및 효율성 개선 논의 • 현재 엑셀에 하나씩 입력하는 방식이 상당히 번거로우므로, 이 과정의 효율성을 개선하는 방법을 모색할 필요가 있다. • 기본 설정이 정해지면 변경되지 않으므로, 받아온 데이터와 차이가 있을 때만 수정하는 방식으로 진행하기로 결정했다. • 개별 항목을 하나씩 올리는 기능은 필수적이지만, 전체적인 입력 부담을 줄이기 위한 개선 방안을 고민해야 한다. 녹선 플랫폼 사용자 추가 및 데이터 입력 프로세스 개선 • 현재 10명에서 20명의 사용자를 개별적으로 추가하고 엑셀에서 드래그하여 복사 붙여넣기로 처리할 수 있다. • 기본 MVP 이후 개선 사항으로 드래그 앤 드롭 기능 등의 편의 기능 추가가 필요하다. • 사용자가 요청한 기능에 대해 구현 가능성을 검토한 후 진행 여부를 결정하는 방식으로 개선 사항을 관리한다. • 품목 관련 항목에서 특히 편의 기능이 필요하며, 추후 일괄 정리 시 이를 반영할 계획이다. 급여 처리 및 AI 시스템 도입 시 검증 문제 논의 • 급여 항목이 세 가지이며, 기존에는 건강보험료 등을 리 어드민에서 관리했으나 노무사가 직접 제공하는 방식으로 변경될 예정이다. • AI 시스템을 내부에 도입할 경우 모든 행위가 토큰으로 처리되며, AI의 할루시네이션 오류로 인해 크로스 체크가 필수적으로 필요하다. 필수 작업 확인 • 반드시 수행해야 할 작업이 있음을 강조하고 있다.