회계 모듈은 어디까지 자동이어야 하는가

매출 발행 · 매입 수취 · 수정 · 취소

네 가지 흐름이 한 화면에서 이어지는지, 수정·취소 후 원장이 어떻게 정리되는지 확인합니다.

발행 화면 ↔ 원장 전표 자동 연결

발행 후 전표가 자동으로 생기지 않으면 결국 사람이 입력합니다. 데모에서 이 연결을 실제로 시켜 봅니다.

규모별 요구 수준

중소기업부터 대기업까지 도입 요구가 넓지만, 요구 수준은 규모에 따라 다릅니다. 본인 규모의 기준으로 다시 봐야 합니다.

매출·매입 증빙과 신고 데이터 대조

어긋나면 마감 때 원인을 찾아야 합니다. 대조가 어디서 끝나는지가 그 달의 부담을 정합니다.

실시간 방식인지 일괄 방식인지

연동 방식에 따라 마감 직전에 몰리는 작업의 양이 달라집니다. 이 항목은 제품 데모에서 가장 과소평가되는 부분입니다.

오류가 났을 때 확인하는 위치

오류 목록이 한 곳에 모이는지, 아니면 담당자가 직접 찾아야 하는지를 봅니다.

지출 · 구매 · 세금계산서 · 정산 승인 연결

회계팀만 쓰는 프로그램이 아니라 전사 운영 시스템으로 확장될 때 중요해집니다.

승인 단계 = 회계 전표 흐름

같은 흐름에 있으면 통제가 되고, 분리되어 있으면 사후 정리가 됩니다. 감사 추적성과 권한관리에 직접 영향을 줍니다.

월말 승인 집중 시 알림 · 대리 결재

마감 일정이 승인 대기로 밀리는 경우를 데모에서 재현하기 어렵습니다. 이 부분은 미리 물어봐야 합니다.

재료비 · 노무비 · 경비 배부 기준

어떤 기준으로 배부되는지가 제품마다 다릅니다. 원가가 틀리면 재무제표도 틀어집니다.

배부 기준을 바꿀 수 있는지

기준을 바꾸는 순간 과거 데이터 전체가 다시 계산되어야 합니다. 이 가능성이 실제 운영 부담을 가릅니다.

과거 데이터 재계산 가능 여부

판가 인상, 생산 방식 변경처럼 기준이 흔들리는 시점을 견디는지 데모에서 확인합니다.

승인 · 조회 · 수정 · 마감 후 변경

네 가지 권한이 별도로 설계되는지, 하나로 묶여 있는지를 먼저 봅니다.

마감 후 수정 권한의 분리 여부

마감 후 수정 권한을 별도로 두는 제품이 있고, 그렇지 않은 제품도 있습니다.

감사 추적과 권한 설계의 관계

감사 추적이 있다고 해도 권한이 느슨하면 기록은 형식이 됩니다. 내부통제는 권한 설계 위에서 작동합니다.