계정과목표 설계

계정과목표는 무엇을 위한 것인가

계정과목표는 회사의 모든 거래가 최종적으로 들어가는 바구니의 목록입니다. 재무제표가 무엇을 말할 수 있는지, 보고서가 어떤 질문에 답할 수 있는지, 그리고 전기된 거래와 쓸모 있는 숫자 사이에 얼마나 많은 수작업이 끼어드는지를 결정합니다. 어떤 회계 시스템에서든 가장 결과가 큰 설정이면서도, 거의 언제나 시스템 도입 중에 그때 시간이 나는 누군가가 서둘러 설계합니다.

더 신경 써야 하는 이유는 비용이 비대칭적이기 때문입니다. 잘 설계하는 데는 며칠의 고민이면 됩니다. 나중에 고치려면 과거 데이터의 비교 가능성을 잃고, 모든 연동에 걸쳐 매핑 작업을 해야 하며, 감사인과 협의해야 합니다. 한 시스템을 5년 넘게 써 온 회사라면 거의 모두 다시 설계한다면 그렇게 하지 않았을, 그러나 쉽게 바꿀 수도 없는 계정과목표를 안고 있습니다.

핵심 설계 질문은 겉보기에는 단순합니다. 무엇을 계정 코드에 넣고, 무엇을 다른 곳에 둘 것인가입니다. 계정과목표 실패의 거의 전부는 이 질문에 대해 계정 코드에 너무 많은 것을 넣는 쪽으로 답한 결과입니다. 그 이유를 이해하려면 계정이 실제로 무엇인지 분명히 해야 합니다.

계정은 이것이 어떤 종류의 금액인가라는 질문에 답합니다. 지급임차료, 매출채권, 상품매출처럼 금액의 성격을 기술하며, 계정이 답해야 하는 질문은 이것뿐입니다. 어디서 발생했는지, 누구를 위한 것인지, 어느 프로젝트, 어느 부서, 어느 제품군인지는 모두 실제로 필요한 질문이지만, 어느 것도 금액의 성격에 관한 질문은 아닙니다.

계정 난립이라는 실패

세상에서 가장 흔한 계정과목표는 대략 이렇게 생겼습니다. 임차료 계정이 하나 있습니다. 회사가 두 번째 지점을 열자 1지점 임차료와 2지점 임차료가 생깁니다. 누군가 부서별 임차료를 보고 싶어 하자 각각이 다시 나뉩니다. 새 코스트센터가 생기면 판매비와관리비 범위의 모든 계정이 그 코스트센터용으로 복제됩니다. 몇 년 안에 계정은 4,000개가 되고, 그 대부분은 1년 중 석 달만 잔액이 있습니다.

이런 구조는 눈에 띄게 실패하지 않습니다. 점점 많은 것을 불가능하게 만드는 방식으로 실패합니다. 통합 보고서를 만들려면 수백 개의 계정을 합산해야 하고, 지점이 새로 생길 때마다 보고서를 다시 만들어야 합니다. 지점을 비교하려면 서로 다른 계정 코드를 비교해야 하는데, 이를 해 주는 표준 보고서는 없습니다. 지점을 닫으면 이력이 있어서 삭제할 수 없는 죽은 계정 20개가 남습니다. 지점을 추가하려면 계정 20개를 만들고, 그것을 모든 보고서, 모든 예산, 모든 매핑에 추가하는 것을 잊지 말아야 합니다. 결국 누군가 2지점 임차료를 1지점 계정에 전기하게 되고, 그 오류는 통합 합계에서는 보이지 않습니다.

더 깊은 비용은 이 구조가 회사에 관한 사실 하나를 원장에 하드코딩해 버렸다는 점입니다. 지점, 부서, 제품군은 바뀝니다. 합쳐지고, 나뉘고, 이름이 바뀌고, 재편됩니다. 그럴 때마다 이를 구조적으로 담고 있는 계정과목표는 다시 만들어야 하고, 누군가 과거와 비교하고 싶어 하는 바로 그 순간에 과거 데이터는 비교할 수 없게 됩니다.

살펴봐야 할 증상은 반복입니다. 계정 목록에서 같은 단어가 일정한 간격으로 되풀이되는 것이 보인다면, 즉 임차료, 임차료, 임차료, 급여, 급여, 급여처럼 보인다면, 그 반복되는 개념은 비용의 종류가 아닙니다. 달리 둘 곳이 없어서 계정 코드 안에 억지로 밀어 넣은 회사의 관리 차원입니다.

계정과 관리 차원

지난 20년 사이에 만들어진 회계 시스템은 거의 모두 계정 코드와 함께 전기 속성을 붙이는 기능을 지원하며, 이를 관리 차원, 세그먼트, 분석 코드, 태그, 코스트센터, 추적 범주 등 다양한 이름으로 부릅니다. 하나의 전기에는 계정과 하나 이상의 관리 차원 값이 함께 담기고, 보고서는 계정별, 관리 차원별, 또는 둘 다를 기준으로 만들 수 있습니다.

이것은 설계 문제를 완전히 바꿉니다. 임차료는 하나의 계정입니다. 지점은 지점마다 값이 하나씩 있는 관리 차원입니다. 2지점 임차료는 별도의 계정이 아니라, 임차료 계정을 2지점으로 필터링한 것입니다. 지점을 추가하면 계정 20개가 아니라 관리 차원 값 하나가 늘어납니다. 지점을 닫으면 값 하나를 사용 중지합니다. 지점 비교는 맞춤 제작이 아니라 그룹화가 들어간 표준 보고서입니다. 그리고 계정 목록은 적정한 크기를 유지하며, 대부분의 중견기업에게 그 크기는 수천 개가 아니라 수백 개입니다.

무언가가 계정인지 관리 차원인지를 가리는 기준은 그것이 금액의 성격을 바꾸는지, 아니면 금액의 맥락을 바꾸는지입니다. 리야드의 임차료와 제다의 임차료는 장소만 다른 같은 종류의 비용이므로 장소는 관리 차원입니다. 지급임차료와 급여는 서로 다른 종류의 비용이므로 서로 다른 계정입니다. 이 기준을 일관되게 적용하면 계정 난립의 대부분을 시작 전에 막을 수 있습니다.

관리 차원에 대해 두 가지를 경고합니다. 첫째, 관리 차원은 의미가 있는 곳에서 필수 입력일 때만 쓸모가 있습니다. 전기의 80퍼센트에만 입력된 관리 차원은 설명되지 않는 나머지가 있는 보고서를 만들어 내고, 그 나머지는 보고서가 아예 없는 것보다 더 빨리 보고서에 대한 신뢰를 무너뜨립니다. 둘째, 시스템이 열 개를 허용한다고 관리 차원을 열 개 정의하고 싶은 유혹을 이겨 내십시오. 모든 관리 차원은 누군가가 모든 거래에서 정확하게 입력해야 하는 필드이며, 입력되지 않은 관리 차원은 없는 관리 차원보다 나쁩니다.

• 지점, 소재지, 사업장, 매장: 관리 차원입니다. 어디서 발생하든 비용의 종류는 같습니다.
• 부서, 코스트센터, 기능: 관리 차원입니다. 무엇을 샀는지가 아니라 누가 책임지는지를 정합니다.
• 프로젝트, 작업, 계약: 관리 차원이며, 보고상 가치가 가장 큰 경우가 많습니다.
• 제품군, 서비스군, 사업부문: 관리 차원이며, 대부분의 부문별 보고의 기초입니다.
• 고객과 공급처: 애초에 계정이 아닙니다. 통제계정 뒤의 보조원장에 속합니다.
• 종업원: 계정이 아닙니다. 급여 명세는 급여 시스템에 두고, 원장에는 요약하여 반영합니다.
• 법인: 대개 관리 차원이 아니라 별도의 원장으로 다루지만, 일부 시스템은 세그먼트로 처리합니다.

코드 체계

계정 코드 체계는 관리 차원 설계보다 덜 중요한데도 더 많이 논쟁거리가 됩니다. 코드 체계가 해야 할 일은 코드만 보고도 계정 유형을 알 수 있게 하고, 번호를 다시 매기지 않고도 계정을 끼워 넣을 여지를 남기며, 별도의 매핑 없이 재무제표 순서대로 정렬되게 하는 것입니다.

일반적인 구조는 재무제표 분류에 따라 묶는 것입니다. 자산, 부채, 자본, 수익, 비용에 각각 첫 자리 숫자나 범위를 주고, 그 안에 계정 유형별 하위 범위를 둡니다. 유동자산은 비유동자산과 분리합니다. 매출원가는 판매비와관리비와 분리합니다. 금융원가는 그 둘 모두와 분리합니다. 구체적인 범위보다 훨씬 중요한 것은 범위가 존재한다는 것, 그리고 그 안의 간격이 계정을 끼워 넣을 만큼 넓다는 것입니다.

계정 이름은 번호만큼 신경 써야 하지만 거의 관심을 받지 못합니다. 이름은 같은 거래를 전기하는 두 사람이 같은 계정을 고를 수 있을 만큼 무엇이 그 계정에 들어가는지 정확하게 기술해야 합니다. 잡비, 기타, 일반, 그 밖의 같은 이름은 그렇게 되지 않을 것을 보장하며, 일반관리비라는 이름의 계정은 누구든 확신이 없는 모든 것을 빨아들입니다. 그런데 그것이야말로 가장 들여다봐야 할 항목들입니다.

• 길이를 통일하십시오. 길이가 섞인 코드는 예측할 수 없게 정렬되고, 코드를 텍스트로 다루는 곳으로 내보내면 깨집니다.
• 간격을 남기십시오. 여유 없이 연속으로 매긴 번호는 1년 안에 번호를 다시 매기거나 순서에서 벗어난 계정을 만들게 합니다.
• 먼저 재무제표 분류로 묶으십시오. 그래야 별도의 매핑 계층 없이 계정 목록이 보고서 순서대로 정렬됩니다.
• 하위 범위에 의미를 유지하십시오. 유동자산 범위에 있는 계정은 유동자산이어야 하며, 과거 사정으로 남겨 둔 예외가 없어야 합니다.
• 번호에 관리 차원을 담지 마십시오. 임차료·2지점을 뜻하는 코드는 변장한 관리 차원입니다.
• 기존 계정의 번호를 다시 매기지 마십시오. 비용은 과거 데이터, 연동, 그리고 코드를 외워 둔 모든 사람에게 떨어지고, 얻는 것은 겉모양뿐입니다.

통제계정, 그리고 직접 전기해서는 안 되는 것

재무상태표 계정 중 일부는 보조원장을 요약합니다. 매출채권, 매입채무, 재고자산, 유형자산, 그리고 대개 세금 계정은 각각 하나의 원장 계정을 가지며, 그 잔액은 다른 곳에 보관된 상세 명세의 합계와 같아야 합니다. 이것이 통제계정이며, 중요한 설계 결정은 통제계정이 직접 전기를 받아서는 안 된다는 것입니다.

사용자가 수동 분개를 매출채권 통제계정에 바로 전기할 수 있으면 통제계정과 보조원장이 어긋나고, 그 차이는 누군가 조정할 때에야 발견됩니다. 통제계정을 전기 불가로 지정하거나, 알려진 오류를 수정하는 소수의 지정된 사람에게만 직접 전기를 허용하면, 매월 수행하는 적발 통제가 구조적인 통제로 바뀝니다. 대부분의 시스템 도입에서 가장 저렴하게 얻을 수 있는 개선 중 하나인데도 설정되지 않는 경우가 매우 많습니다.

이와 관련된 구조적인 요점은 모든 계정이 전기 가능해야 하는 것은 아니라는 점입니다. 잘 만든 계정과목표에는 묶고 보고하기 위해 존재하는 상위 계정 또는 집계 계정이 있고, 그 아래에 전기 가능한 계정이 있습니다. 상위 계정에 전기하면 계층 구조가 무너지고, 합계에는 나타나지만 그 구성 요소 어디에도 나타나지 않는 잔액이 생깁니다. 보고서가 할 수 있는 일 중 가장 혼란스러운 일 가운데 하나입니다.

가계정도 똑같이 명시적으로 설계해야 합니다. 입고되었으나 세금계산서가 오지 않은 물품, 급여 가계정, 내부거래 정리 계정, 미착 재고, PG 정산 계정은 각각 계정과목표를 설계하는 시점에 정상 잔액과 지정된 담당자를 명시하여 정의해야 합니다. 나중에 처음으로 무언가를 둘 곳이 필요했던 사람이 즉흥적으로 만들게 해서는 안 됩니다. 즉흥적으로 만든 계정은 결코 검토되지 않습니다.

작성해야 하는 재무제표에 맞춰 설계하기

계정과목표는 그것이 공급해야 하는 산출물에서 거꾸로 설계해야 합니다. 산출물은 대개 네 가지입니다. 법정 재무제표, 관리회계 보고서, 세무 신고서, 그리고 모회사나 대주가 요구하는 것입니다. 이들은 각각 일정한 수준의 상세함을 요구하며, 계정과목표는 그중 가장 세밀한 수준을 담을 수 있어야 합니다.

IAS 1은 특정 항목을 주요 재무제표 본문에 표시하도록 요구하고, 중요하지 않은 항목은 통합하되 추가 내용은 주석에 기재하도록 허용합니다. 이는 계정과목표 요건이 아니라 표시 요건이지만, 계정과목표 요건을 낳습니다. 재무제표나 주석에서 따로 공시해야 하는 항목은 계정이든 관리 차원이든 원장에서 따로 식별할 수 있어야 합니다. 감가상각비, 종업원급여, 금융원가, 손상차손이 흔한 예이며, 이것들을 일반 범주로 뭉뚱그린 계정과목표로는 매년 분석 작업을 하지 않고서는 공시를 만들 수 없습니다.

세무에는 고유한 요건이 있으며, 회계 요건과 다릅니다. 손금불산입 비용은, 접대비가 대표적인 예인데, 처음부터 별도 계정에 전기해 두었다면 매년 일반 계정에서 추려 낼 필요 없이 훨씬 쉽게 식별할 수 있습니다. 공제받을 수 없는 매입세액, 그리고 세무상 처리가 다른 모든 범주도 마찬가지입니다.

관리회계 보고는 대개 법정 보고와 정반대를 원합니다. 구조는 덜, 관리 차원은 더 원합니다. 제품군별 매출총이익, 부서별 비용, 지점별 공헌이익을 원하는데, 법정 재무제표는 이 중 어느 것에도 관심이 없습니다. 계정과 관리 차원을 나누는 것이 올바른 아키텍처인 이유가 바로 이것입니다. 계정은 법정 관점을, 관리 차원은 관리 관점을 담당하며, 두 관점 모두 두 번째 장부 없이 같은 전기에서 나옵니다.

복수 법인과 연결

그룹에 여러 법인이 있다면 가장 강력한 방식은 모든 법인이 사용하는 단일한 그룹 계정과목표를 두고, 현지 법률이 정말로 요구하는 경우에만 법인별 계정을 추가하는 것입니다. 그러면 연결은 매 기간 유지하고 다시 검증해야 하는 매핑 작업이 아니라, 같은 계정을 합산하고 내부거래 잔액을 제거하는 일이 됩니다.

흔한 반론은 법인마다 다르다는 것이고, 실제로 다르긴 하지만 생각보다는 덜 다릅니다. 상사 회사와 서비스 회사는 대체로 같은 비용 구조를 씁니다. 다른 것은 어떤 계정을 쓰느냐이지 계정이 무엇을 뜻하느냐가 아닙니다. 법인에서 쓰지 않는 계정은 비용이 들지 않습니다. 법인 간에 계정의 의미가 다르면 매달 조정 비용이 들고, 아무도 분해할 수 없는 연결 숫자가 나옵니다.

법인들이 서로 다른 계정과목표를 물려받은 경우, 그리고 회사를 인수하는 그룹이라면 대부분 그렇게 되는데, 이를 변환하는 매핑 계층은 영구적인 부담입니다. 어느 쪽 계정과목표가 바뀌어도 유지보수해야 하고, 검증해야 하며, 연결 결과물에서는 보이지 않습니다. 그래서 매핑의 오류는 어느 법인을 조정해도 발견되지 않는 방식으로 틀린 연결 숫자를 만들어 냅니다. 공통 계정과목표로 수렴하는 데는 한 번 큰 비용이 들지만 그 뒤로는 더 저렴합니다.

내부거래 계정은 명시적이고 짝을 이루어야 합니다. 모든 법인과의 순잔액을 담는 하나의 내부거래 계정이 아니라, 상대 법인별로 별도의 채권 계정과 채무 계정을 두어야 합니다. 연결 시 제거는 각 잔액이 어느 법인과의 것인지 아는 데 달려 있으며, 하나의 계정에 담긴 순잔액은 누군가 손으로 추가 분석을 하지 않고서는 제거할 수 없습니다.

실제로 설계하는 방법

방법은 짧으며, 규율은 흔히 그렇듯 계정 목록으로 바로 건너뛰지 않고 순서를 따르는 데 있습니다.

설계 오류를 찾아내는 것은 여섯 번째 단계이며, 중복 작업처럼 느껴져서 가장 자주 생략되는 단계이기도 합니다. 중복 작업이 아닙니다. 실제 한 달치 거래로 실제 법정 재무제표, 실제 관리회계 보고서, 실제 세무 계산을 만들어 보면 보고할 수 없는 세 가지가 오후 한나절 만에 드러납니다. 그때 찾으면 비용이 들지 않습니다. 넉 달째에 찾으면 아래에서 설명하는 변경 비용이 듭니다.

• 산출물을 먼저 나열하십시오. 법정 재무제표, 세무 신고서, 관리회계 보고서, 대주나 모회사의 요구사항입니다. 이것이 최소한의 상세 수준을 정합니다.
• 관리 차원을 식별하십시오. 사업 전반을 짚어 가며 누군가 숫자를 나눠 보고 싶어 할 모든 방식을 적으십시오. 금액의 성격을 바꾸지 않는 한 각각이 관리 차원입니다.
• 그런 다음에야 계정 목록을 작성하십시오. 재무제표 구조에서 아래로 내려가며 작성하고, 더 나누면 성격이 아니라 관리 차원에 관한 질문에 답하게 되는 수준에서 멈춥니다.
• 통제계정과 상위 계정을 전기 불가로 지정하고, 모든 가계정을 정상 상태와 담당자를 정해 의도적으로 정의하십시오.
• 전기 규칙을 작성하십시오. 각 거래 유형이 어느 계정에 대응하는지를 정하는 것으로, 감사 추적이 실제로 끊기는 곳이 바로 이 매핑 계층이기 때문입니다.
• 전년도 데이터로 시험하십시오. 실제 거래 한 기간을 새 구조에 전기한 다음, 그 결과로 네 가지 산출물을 모두 만들어 봅니다.
• 문서로 남기십시오. 각 계정에 무엇이 들어가는지 적은 문서가 없는 계정 목록은 1년 안에 사람마다 다르게 해석됩니다.

나중에 바꾸면 드는 비용

계정과목표는 실제로 바뀌며, 비용은 변경 자체가 아닙니다. 계정을 만드는 것은 사소한 일입니다. 비용은 기존 구조에 연결된 모든 것이며, 그 대부분은 계정 목록에서 보이지 않습니다.

그런 이유로 대부분의 변경은 구조적인 것이 아니라 추가적인 것이어야 합니다. 계정을 하나 추가하거나, 회계연도 시작 시점부터 장래적으로 한 계정을 둘로 나누거나, 기존 구조와 나란히 관리 차원을 도입하는 것은 모두 감당할 수 있습니다. 계정과목표 전체의 번호를 다시 매기거나, 이력이 있는 계정을 합치거나, 기존 계정의 의미를 바꾸는 것은 그렇지 않습니다. 그중 마지막이 가장 나쁩니다. 눈에 보이게 깨지는 것이 없고, 보고서가 그저 틀려질 뿐이기 때문입니다.

구조적 변경의 적절한 시점은 회계연도 시작이며, 계획을 세우고, 기존 구조와 새 구조를 문서화하고, 매핑을 영구 보관하고, 변경 후 첫 기간을 양방향으로 조정해야 합니다. 급한 보고 문제를 해결하려고 회계연도 중간에 바꾸면 아무것과도 비교할 수 없는 1년치 장부가 남습니다.

• 과거 데이터. 과거 거래는 과거 계정에 있습니다. 과거 데이터를 다시 매핑하여 이미 전기된 기간을 바꾸거나, 비교 정보가 단절을 가로지른다는 것을 받아들이고 모든 전년 대비 보고서에 연결표를 두어야 합니다.
• 매핑. 모든 연동, 모든 전기 규칙, 모든 은행 거래 자동 분류 규칙, 모든 반복 분개, 모든 가져오기 템플릿이 계정 코드를 참조하므로 하나하나 찾아서 수정해야 합니다.
• 보고서. 재무제표 양식, 관리회계 보고서, 예산, 대시보드, 코드로 시산표를 끌어오는 모든 스프레드시트가 깨지며, 오류를 내는 것이 아니라 새 계정을 빠뜨리는 방식으로 조용히 깨집니다.
• 예산과 전망. 기존 구조로 만든 예산은 매핑 없이는 새 구조의 실적과 비교할 수 없으며, 그 매핑 자체가 오류의 원천입니다.
• 사람. 세금계산서에 계정을 지정하는 사람은 모두 코드를 외우고 있으며, 전환 기간에는 잘못된 전기가 생겨 다시 수정해야 합니다.
• 감사. 감사인은 변경 내용을 이해하고, 재작성된 비교 정보가 일관된다는 확신을 얻고, 매핑을 테스트해야 합니다. 이는 현장 감사 중이 아니라 미리 나눠야 할 대화입니다.

설계가 잘못되었다는 신호

대부분의 회사는 검토하도록 강제하는 계기가 없기 때문에 계정과목표를 검토하지 않습니다. 다음은 계정과목표가 비용을 발생시키고 있다는 신호이며, 모두 별도 프로젝트 없이도 확인할 수 있습니다.

이 중 어느 것도 그것만으로 치명적이지는 않습니다. 여러 개가 함께 나타난다면 구조가 그 뒤로 바뀐 회사의 사실을 담고 있다는 뜻이며, 그 위에 만든 모든 보고서가 조용히 그 비용을 떠안고 있는 것입니다.

• 계정 목록 곳곳에 같은 단어가 반복됩니다. 관리 차원이 계정 코드에 담겨 있다는 뜻입니다.
• 당해 연도에 거래가 없는 계정의 비중이 큽니다. 구조가 그것이 기술하던 조직보다 오래 살아남았다는 뜻입니다.
• 관리회계 보고서를 만들려면 계정을 보고서 항목에 매핑하는 스프레드시트가 필요하고, 그것을 한 사람이 관리합니다.
• 일반관리비나 잡비 계정에 중요한 금액의 잔액이 있습니다. 사람들이 무엇을 어디에 넣어야 할지 모른다는 뜻입니다.
• 지점별 비용이나 제품군별 이익률 같은 일상적인 질문에 답하는 데 보고서가 아니라 데이터 추출이 필요합니다.
• 새 지점이나 부서를 여는 일이 관리 차원 값 하나를 추가하는 것이 아니라 설정 프로젝트가 됩니다.
• 특정 비용이 어디에 전기되는지 두 사람에게 물으면 서로 다른 답이 나옵니다.

거버넌스

계정과목표는 시간에 쫓겨 내린 작은 결정들로 망가집니다. 누군가 새 비용을 위한 계정이 필요해서 하나를 만들고, 공급처 이름을 붙이고, 거기에 전기합니다. 5년 뒤에는 그런 계정이 200개가 되고, 신중하게 설계했던 구조는 아무도 결정하지 않은 것들로 희석됩니다.

통제 방법은 평범하지만 효과적입니다. 계정을 만들거나 바꾸려면 문서화된 구조 정의에 비추어 지정된 사람의 승인을 받아야 하고, 변경은 기록됩니다. 승인자는 한 가지만 묻습니다. 새로운 것이 다른 종류의 금액인가, 아니면 기존 금액의 다른 맥락인가. 요청의 대부분은 후자이며, 그 답은 계정이 아니라 관리 차원 값입니다.

Skyline Nexus는 지점과 사업장을 거래 자체에 담고, 모든 원장 라인이 그것을 만든 문서로 연결되므로, 지점별 조회는 계정 코드로 다시 짜 맞춘 구조가 아니라 원천과의 조인입니다. 이 시스템을 포함해 어떤 시스템에 대해서든, 원장 라인(LINE)이 정확히 어떤 관리 차원을 저장하고 어떤 관리 차원은 원천 문서에만 있는지 물어볼 가치가 있습니다. 그 차이가 관리 차원별 보고서가 직접 조회인지 재구성인지, 그리고 문서 유형이 바뀌어도 살아남는지를 결정합니다. 이것은 시스템이 무엇을 보관하는지에 대한 설명입니다. 귀사의 설계를 대신 정해 주지는 않으며, 관리 차원이어야 했던 것을 계정 코드에 담는 계정과목표를 막아 주는 시스템은 없습니다.

• 각 계정에 무엇이 들어가는지 명시하고 최신 상태로 유지하는 계정과목표 문서.
• 계정 생성과 수정은 제한하고 승인을 받으며, 사유를 기록.
• 거래가 없는 계정과 잡다한 항목을 빨아들이는 계정에 대한 연례 검토.
• 원천 시스템이 바뀔 때마다 전기 규칙과 매핑을 검토. 감사 추적이 끊기는 곳이 여기이기 때문입니다.
• 관리 차원 값도 계정과 같은 방식으로 관리. 통제되지 않는 관리 차원 목록은 그 자체로 또 하나의 난립이 되기 때문입니다.

합리적인 기본형

특별한 보고 요건이 없는 회사라면 다음 형태가 잘 작동하며, 명시된 이유가 있을 때만 벗어날 가치가 있습니다. 재무제표 분류로 묶고 간격을 넓게 둔 수백 개의 계정. 금액의 성격이 다르거나 법정 공시나 세무 공시가 요구할 때만 나누는 계정. 관리 차원은 세 개에서 다섯 개이며, 흔히 지점 또는 사업장, 부서 또는 코스트센터, 프로젝트로 구성됩니다. 통제계정과 상위 계정은 전기 불가. 가계정은 정의되어 있고 담당자가 있음. 그리고 무엇이 어디에 속하는지에 대한 문서화된 정의.

이 구조는 하나의 전기 집합에서, 매핑 스프레드시트 없이 법정 재무제표, 여러 방식으로 나눠 본 관리회계 보고서, 세무 계산을 만들어 냅니다. 새 지점, 조직 개편, 기업 인수를 구조 개편 프로젝트 없이 견뎌 냅니다. 그리고 세금계산서에 계정을 지정하는 사람이 올바른 계정을 찾을 수 있을 만큼 계정 목록을 작게 유지합니다. 결국 나머지 모든 것이 제대로 작동하느냐를 결정하는 제약 조건은 바로 이것입니다.

계정과목표는 재무 시스템에서 한 시간의 설계가 1년의 작업을 아껴 주는 유일한 부분이며, 잘못했을 때의 결과가 너무 천천히 나타나서 아무도 그 원인과 연결하지 못하는 부분입니다. 시스템을 도입하고 있다면 며칠을 투자하십시오. 이미 운영 중이고 위의 증상을 알아보셨다면, 그대로 안고 살기보다는 회계연도 말에 맞춰 변경을 계획하고, 가능한 한 추가적인 방식으로 바꾸십시오.