2026-11-09 클라우드회계가이드
검토 항목 · 연동과 데이터

연동이 끊기면 장부도 끊깁니다

은행 거래, 카드, 급여, 구매, 재고가 장부로 흘러 들어오는 경로가 정리되어야 전표 입력이 줄어듭니다. 이 페이지는 연동 범위와 데이터 소유권을 어떻게 검토할지 다룹니다.

01

은행·카드 거래 연동

계좌 조회 · 거래 수집 · 장부 매칭이 모두 자동인지, 매칭 규칙을 자사 패턴으로 저장할 수 있는지

자동 (매칭 제외)

조건부
02

급여·구매·재고 모듈

급여 결과가 회계 전표로, 매입 채무와 원가 계산이 어느 계정과목으로 생성되는지

모듈 결합 여부

조건부
이 항목은 검토를 마쳤습니다

데이터 소유권 · 보관 위치

계약 종료 시 반출 형식, 백업 주기, 접근 권한 기록이 남는지

감사 가능

지원
04

API · 그룹웨어 결합

표준 커넥터로 끝나는지, 결재 승인이 지출 전표로 자동 반영되는지

별도 개발

미지원

연동은 "가능하다"와 "우리 환경에서 돌아간다"가 다릅니다. 경로별로 확인하십시오. 비교 범위는 솔루션 비교 페이지에서 전체 조건과 함께 볼 수 있습니다.

통합 장비 캐비닛과 서버 랙, 문서 트레이, 데스크톱 PC가 그려진 일러스트
연동·데이터 관리 데이터가 어디에 어떻게 쌓이는지 확인하는 장면
이 페이지가 다루는 것

클라우드 회계의 실질적인 가치는 연동에서 나옵니다. 은행 거래, 카드, 급여, 구매, 재고가 장부로 흘러 들어오는 경로가 정리되어야 전표 입력이 줄어듭니다. 이 페이지는 연동 범위와 데이터 소유권을 어떻게 검토할지 다룹니다.

01 · 계좌에서 장부로

은행·카드 거래 연동

은행 거래 연동은 계좌 조회, 거래 내역 수집, 장부 매칭으로 나뉩니다. 어디까지 자동이고 어디부터 수동인지가 실무 시간을 결정합니다. 매칭 규칙을 자사 패턴에 맞게 저장할 수 있는지도 확인 항목입니다.

계좌 조회

잔액이 실시간으로 확인되는지, 하루에 몇 번 동기화되는지. 조회 주기가 재무팀의 오전 업무 흐름에 맞는지 봅니다.

거래 내역 수집

수집된 거래가 전표 후보로 놓이는지, 담당자가 어떤 기준으로 걸러내는지. 수집 누락이 생겼을 때 어디서 확인할 수 있는지도 확인 지점입니다.

장부 매칭

거래처 이름, 금액 구간, 적요 키워드로 매칭 규칙을 저장할 수 있어야 매달 같은 작업을 반복하지 않습니다. 규칙이 몇 개까지 쌓이는지도 확인하십시오.

카드 사용 내역은 승인 시점과 매입 시점이 달라 계정 처리가 갈립니다. 이 차이를 제품이 어떻게 다루는지 미리 봐 두면 월말 정리 시간이 줄어듭니다. 승인일 기준으로 전표를 잡는지, 매입 확정일 기준인지 두 가지 모두를 지원하는지 비교 항목으로 정리해 두면 검토가 빨라집니다.

02 · 급여·구매·재고

급여·구매·재고 모듈 연결

모듈이 회계와 결합할수록 전표 입력은 줄지만, 초기 설정과 유지보수 범위도 늘어납니다.

MODULE 02-A

급여 결과가 전표로 넘어오는 경로

급여를 별도 프로그램으로 처리하고 있다면, 그 결과가 회계 전표로 어떻게 넘어오는지가 관건입니다. 인건비 계정과 원천세 항목이 자동으로 생성되는지 확인하십시오. 매달 사람이 다시 옮겨 적는 구조라면 절감 폭이 거의 없습니다.

  • 인건비 계정 자동 생성 여부
  • 원천세·4대보험 항목의 분리 처리
  • 급여 프로그램의 데이터 추출 형식
확인 대상 · 급여 모듈 전표 자동생성 여부
MODULE 02-B

구매·재고가 원가로 이어지는 길

구매와 재고는 매입 채무와 원가 계산에 직접 연결됩니다. 발주 → 입고 → 송장 → 지급 순서가 하나의 흐름으로 이어지는지, 중간에 사람이 손으로 옮기는 단계가 남는지가 검토 지점입니다.

Odoo Accounting은 판매, 재고, 프로젝트, CRM과의 결합이 쉬운 편으로 알려져 있어, 이 범위를 한 시스템에서 다루려는 조직이 검토합니다. 반대로 회계만 필요한 조직에는 불필요한 복잡도가 될 수 있습니다.

03 · API · 그룹웨어

API와 연동 방식

API 연동은 커스텀 개발이 필요한 영역입니다. 표준 커넥터로 끝나는지, 별도 개발이 필요한지에 따라 일정과 비용이 달라집니다. 개발을 누가 맡고, 이후 유지보수를 누가 하는지도 함께 정하십시오.

그룹웨어 · 전자결재

결재 승인 결과가 지출 전표로 자동 반영되는지, 담당자가 다시 입력해야 하는지

별도 개발 · 유지보수 필요

미지원

회계 API · 표준 커넥터

벤더가 제공하는 공식 커넥터 목록과 올해 이후 지원 중단 예정 여부

표준 범위 내

지원

은행 거래 수집

주요 시중은행 계좌 커버리지와 신규 계좌 추가 절차

표준 범위 내

지원

자체 개발 확장

사내 시스템에 장부 데이터를 넘길 때 필요한 인증 방식과 호출 한도

별도 개발 · 유지보수 필요

조건부

전자결재나 그룹웨어와의 연결도 같은 범주입니다. 결재 승인 결과가 지출 전표로 자동 반영되는지, 아니면 담당자가 다시 입력해야 하는지 확인하면 실제 절감 폭이 보입니다. 별도 개발이 필요한 항목은 견적에 개발 공수와 이후 유지보수 담당을 함께 적어 두는 편이 안전합니다.

04 · 되돌리기 어려운 결정

데이터 소유권과 보관 위치

장부 데이터를 어디에 두는지는 되돌리기 어려운 결정입니다. 계약서에 남겨 두어야 할 조건을 먼저 정리하십시오.

클라우드와 자체 호스팅 중 어느 쪽을 택하든, 서비스 종료 시 데이터를 어떤 형식으로 반출할 수 있는지 계약에 남겨야 합니다. 반출 형식을 규정하지 않으면 이전 시점에 사람이 다시 만들어야 하는 상황이 생깁니다.

반출 형식

CSV·엑셀 내보내기만 되는지, 계정과목과 전표 묶음이 그대로 옮겨지는 구조인지. 복원 가능 여부까지 확인하십시오.

백업 주기와 보관 기간

매일 백업인지, 국내외 어느 리전에 있는지. 보관 기간이 세무 관련 법정 보존 기간과 어긋나지 않는지 확인 항목입니다.

접근 권한 기록

개인정보와 재무 데이터가 섞이는 만큼, 접근 권한 기록이 남는지도 확인 항목입니다. 누가 언제 어떤 전표를 열람·수정했는지 조회할 수 있어야 합니다.

Akaunting처럼 자체 호스팅과 클라우드 사용 사례가 모두 있는 제품은 이 선택지가 넓습니다. 대신 서버 운영과 업데이트 책임이 자사로 넘어옵니다. 누가 그 일을 맡을지 정하지 않으면 운영 공백이 생깁니다.

검토 완료 · 이 한 줄만 따로 봅니다

감사 흔적이 남는 연동

·

전표 발행·수정

작성자, 수정 시각, 이전 값과 이후 값이 함께 남는지

전표 이력 조회

·

계좌 잔액 확인

누가 어느 계좌의 잔액을 열람했는지, 열람 기록이 기간 단위로 남는지

권한 이력 리포트

이 항목은 검토를 마쳤습니다

데이터 반출 요청

요청자, 승인자, 반출 파일 형식과 시각이 세무 대응용 기록으로 남는지

반출 기록 조회

·

권한 변경

담당자 이동·퇴사 시점에 권한이 회수되고 그 기록이 남는지

변경 이력 조회

세 가지 기록이 다 남는 제품이 실무 시간을 가장 많이 줄여 줍니다. 세무 대응 시점에 담당자가 스크린샷을 모으고 있다면, 그 자체가 다음 검토의 신호입니다.

05 · 옮기는 일부터

데이터 마이그레이션 준비

기존 장부를 옮기는 작업은 예상보다 오래 걸립니다. 이관 범위와 검증 절차를 먼저 정해 두면 일정이 흔들리지 않습니다.

  1. 진단

    계정과목 매핑표부터

    이관 대상 기간, 이관할 과거 전표 범위, 남길 계정과목과 통합할 계정과목을 표로 정리합니다. 계정과목 매핑표를 먼저 만들면 이후 작업이 단순해집니다.

  2. 이관·병행

    기준일을 정해 두 시스템으로

    병행 운영 기간에 양쪽 숫자를 비교하려면 기준일을 정해야 합니다. 이 기준일이 없으면 차이 원인을 찾는 데 시간이 걸립니다.

    잔액·채권채무·재고 수량 세 가지를 기준일 시점에 맞춰 놓고, 매주 한 번씩 어긋남을 확인하는 편이 안전합니다.

  3. 안정화

    룰을 남기는 단계

    매칭 규칙, 자주 쓰는 전표 양식, 결재선을 저장해 다음 달부터 손이 덜 가도록 정리합니다.

06 · 장부 앞뒤의 흐름

지급·수금 자동화와의 연결

이 범주는 직접 장부를 대체하기보다 장부 앞뒤의 흐름을 다룹니다. 지급 건수가 많은 조직이라면 회계 시스템과 어디서 접점을 만들지 정하는 것이 검토의 출발점입니다.

지급·수금 담당자의 책상과 서류 트레이가 그려진 일러스트
지급·수금 접점 승인 → 지급 → 장부 반영 순서
Bill.com

미국의 지급·수금 자동화 플랫폼으로 AP/AR를 디지털화합니다. 회계시스템과 연동해 송장 승인, 지급, 수금 흐름을 자동화하는 구조로 알려져 있습니다. 지급 건수가 많고 결재 라인이 긴 조직이 접점 후보로 검토합니다.

Basware

구매부터 송장, 지급까지의 프로세스 자동화를 다루며, 대규모 조직의 비용통제와 컴플라이언스에 맞춰져 있습니다. 이 범주 도입은 통제 체계를 어디에 두는지와 함께 검토되는 편입니다.

접점 확인 항목

송장 승인 결과가 지출 전표로 자동 반영되는지, 지급 완료 상태가 회계 시스템에 어떤 주기로 돌아오는지, 두 시스템의 거래처 코드를 누가 맞추는지 순서로 확인하십시오.

검토 범위 밖

지급·수금 자동화는 회계 모듈 자체의 세무 신고 기능을 대체하지 않습니다. 부가가치세 신고와 법인세 관련 처리는 국내 세무 조건 페이지에서 다룹니다.

서울 스카이라인과 창틀이 그려진 일러스트
검토 마무리 장부를 한 시스템에 두기 전, 오늘 결정할 조건
다음 검토

오늘 정해 두면 편한 세 가지

연동 검토는 결국 세 줄로 정리됩니다. 이 세 줄이 정해지면 이후 비교는 훨씬 빠릅니다.

  1. 1

    장부 데이터를 클라우드에 둘지, 자체 서버에 둘지. 서버 운영을 맡을 담당자를 지금 이름으로 표기해 두십시오.

  2. 2

    이관 대상 기간과 기준일. 잔액·채권채무·재고 수량을 맞춰 볼 날짜 한 곳을 정합니다.

  3. 3

    별도 개발이 필요한 연동 목록과 그 담당자. 견적 단계에서 개발 공수와 유지보수 주체를 함께 적어 두십시오.

검토 중 자주 나오는 질문

연동과 데이터, 이 세 가지만 짚습니다

검토 회의에서 가장 자주 반복되는 질문 세 가지를 정리했습니다.

은행 거래 연동은 국내 은행이면 다 되는 건가요?

주요 시중은행 계좌는 대부분 표준 커넥터로 조회됩니다. 다만 거래 수집 주기, 매칭 규칙 저장 개수, 신규 계좌를 추가할 때의 절차는 제품마다 다릅니다. 실제 계좌로 며칠간 병행 조회를 해 보고 어긋남이 있는지 확인하는 편이 안전합니다.

자체 호스팅을 택하면 서버 운영은 누가 하나요?

서버 패치, 백업, 장애 대응이 모두 자사 몫이 됩니다. 담당자를 이름으로 지정하고, 연간 유지보수 항목 목록을 함께 만들어 두십시오. 이 담당이 비어 있으면 도입 후 첫 번째 장애에서 운영 공백이 그대로 드러납니다.

전표를 옮길 때 잔액이 안 맞으면 어떻게 하나요?

기준일을 정하고 그 날짜에 잔액·채권채무·재고 수량 세 항목을 각각 맞춰 봅니다. 어긋남은 대개 과거 전표 누락, 계정과목 매핑 오류, 재고 수량 단위 차이에서 나옵니다. 이 세 갈래로 원인을 좁히면 훨씬 빨리 찾습니다.

이 페이지에서 다룬 범위는 연동과 데이터에 한정됩니다. 조건 비교, 국내 세무 처리, 도입 절차는 각 페이지에서 이어집니다.