Notion 인보이스 관리 템플릿, 예쁜 장부보다 돈이 들어오는 흐름을 만드세요

Notion이 잘 맞는 사람과 회계 프로그램이 필요한 사람

Notion 인보이스 관리 템플릿은 모든 사업자에게 같은 효율을 주지 않습니다. 한 달에 몇 건에서 수십 건 정도의 청구를 직접 관리하고, 거래처별 진행 상황을 유연하게 보고 싶은 1인 사업자에게 특히 잘 맞습니다.

Notion으로 직접 관리해도 충분한 경우

• 인보이스 발행 건수가 많지만 거래 구조는 비교적 단순한 경우
• 견적, 계약, 작업, 청구, 입금 기록을 서로 연결하고 싶은 경우
• 거래처별 지급 조건과 연락 기록을 함께 남겨야 하는 경우
• 회계 프로그램 밖에서 업무 진행 상황을 별도로 관리하고 싶은 경우
• 모바일에서 입금 확인이나 상태 변경만 빠르게 처리하고 싶은 경우

예를 들어 콘텐츠 제작자는 프로젝트 마감일과 인보이스 발행일이 다를 수 있습니다. 컨설턴트는 월정액 고객과 단발성 고객을 함께 관리해야 하고, 해외 거래가 있는 프리랜서는 통화와 송금 수수료까지 확인해야 합니다.

회계·세금계산서 프로그램이 중심이 되어야 하는 경우

• 전자세금계산서 발행과 신고 자료 생성을 한곳에서 처리해야 하는 경우
• 복식부기, 재고, 원가, 급여 또는 카드 매입 자료까지 관리해야 하는 경우
• 직원별 승인 절차와 세부 권한 통제가 필요한 경우
• 거래 건수가 많아 통장 내역과 자동 대사가 필요한 경우
• 감사나 투자 실사를 대비해 체계적인 회계 기록이 필요한 경우

이런 상황에서는 회계 프로그램을 중심에 두고 Notion을 보조 관리판으로 사용하는 편이 안전합니다. Notion은 업무의 맥락을 잘 보여주지만, 세무 시스템의 역할까지 떠안기면 작은 노트에 금고 문을 달려는 모양새가 됩니다.

직접 관리와 전문 도구 비교

선택지	잘 맞는 상황	장점	주의할 점
Notion 단독 관리	소규모·단순 거래	자유로운 구성, 낮은 초기 비용	세금계산서와 회계 처리는 별도
Notion과 회계 도구 병행	청구 흐름과 세무 처리를 모두 관리	업무 맥락과 공식 기록을 분리 가능	중복 입력을 줄이는 규칙 필요
회계 프로그램 중심	거래량이 많거나 복식부기 필요	정산, 신고, 증빙 관리에 유리	프로젝트 진행 상황은 부족할 수 있음

클라이언트 정보와 작업 이력까지 함께 정리하려면 프리랜서형 클라이언트 관리 구조를 먼저 만들고 인보이스 데이터베이스를 연결하는 방법도 실용적입니다.

인보이스 원본과 관리 기록을 먼저 분리하세요

인보이스 관리가 꼬이는 가장 흔한 이유는 서로 다른 역할의 문서를 한 덩어리로 취급하기 때문입니다. 견적서, 인보이스, 세금계산서, 입금증은 비슷해 보이지만 각각 답하는 질문이 다릅니다.

네 가지 문서는 서로 다른 순간을 기록합니다

문서	답하는 질문	관리 시점
견적서	얼마에 어떤 일을 제공할 것인가	계약 전
인보이스	언제까지 얼마를 지급해야 하는가	납품 전후 또는 계약상 청구일
세금계산서	세법상 거래와 세액을 어떻게 증명하는가	관련 세법과 거래 조건에 따른 시점
입금증·거래 내역	실제로 얼마가 언제 들어왔는가	입금 확인 후

Notion 데이터베이스의 한 행은 이 문서들을 대신하는 원본이 아니라, 한 거래의 진행 상태를 연결하는 색인입니다. 도서관 카드가 책 자체는 아니지만 어느 서가에 무엇이 있는지 알려주는 것과 같습니다.

‘발행 완료’와 ‘세금계산서 완료’를 분리하세요

인보이스를 거래처에 전달했다고 해서 세금계산서 처리까지 끝난 것은 아닙니다. 진행 상태와 세금계산서 상태를 별도 속성으로 만들면 한쪽만 처리된 거래를 찾을 수 있습니다.

• 진행 상태: 작성 중, 발행 예정, 입금 대기, 부분 입금, 입금 완료, 연체, 취소
• 세금계산서 상태: 미발행, 발행 완료, 수정 필요, 해당 없음

전자세금계산서 발행 의무와 시기는 사업자 유형 및 거래에 따라 달라질 수 있습니다. Notion 상태값만 믿지 말고 실제 발행 내역을 공식 시스템에서 대조해야 합니다.

원본은 파일로 보관하고 Notion에는 위치를 연결하세요

발송한 인보이스는 수정 가능한 페이지 상태로만 남기지 말고 PDF 원본을 보관하는 편이 좋습니다. 거래처에 보낸 최종본, 수정본, 계약서, 입금 확인 자료가 섞이지 않도록 폴더명과 파일명을 통일하세요.

• 폴더 예시: 연도 → 거래처 → 프로젝트
• 파일명 예시: 인보이스번호_거래처_발행일_버전
• 수정본 예시: 기존 파일을 덮어쓰지 않고 수정일 또는 버전 추가
• Notion 기록: 파일 직접 첨부 또는 클라우드 저장 위치 연결

필수 속성 16개로 청구 흐름 만들기

처음부터 수십 개 속성을 만들 필요는 없습니다. 청구 시점, 금액, 입금 여부, 증빙 위치를 판단하는 데 필요한 16개부터 시작하면 됩니다.

식별과 일정에 필요한 속성

속성	권장 형식	쓰임
1. 인보이스 번호	제목 또는 식별자	수정본과 거래 내역을 구분
2. 거래처	관계형 또는 선택	고객별 청구 이력 연결
3. 프로젝트명	텍스트 또는 관계형	같은 거래처의 여러 업무 구분
4. 발행 예정일	날짜	아직 발행하지 않은 청구 발견
5. 발행일	날짜	문서가 최종 확정된 시점 기록
6. 발송일	날짜	거래처에 실제 전달한 시점 기록
7. 지급기한	날짜	입금 예정과 연체 판단

금액과 입금에 필요한 속성

속성	권장 형식	쓰임
8. 공급가액	숫자	세금 제외 거래 금액 기록
9. 부가세	숫자	부가세를 별도로 확인
10. 총 청구액	수식 또는 숫자	거래처가 지급해야 할 전체 금액
11. 통화	선택	원화와 외화를 구분
12. 진행 상태	상태	작성부터 연체까지 현재 위치 표시
13. 실입금액	숫자	수수료 또는 부분 입금 반영
14. 입금일	날짜	현금 흐름과 월별 입금 집계

세무와 증빙에 필요한 속성

속성	권장 형식	쓰임
15. 세금계산서 상태	선택	인보이스 상태와 별도로 세무 처리 확인
16. 증빙 묶음	파일 또는 링크	PDF, 계약서, 세금계산서, 입금증 연결

해외 거래가 있다면 환율 기준일, 실제 원화 입금액, 송금 수수료를 추가하세요. 지급 조건이 거래처마다 다르다면 담당자 이메일, 최근 연락일, 최근 독촉일도 유용합니다.

해외 고객에게 보내는 문서 자체의 구성은 해외 클라이언트용 인보이스 항목 안내와 함께 확인하면 관리 기록과 발송 문서를 분리하기 쉽습니다.

청구 한 건이 입금으로 돌아오는 7단계

인보이스 관리는 발송 버튼을 누른 뒤부터 본격적으로 시작됩니다. 계약 확정에서 입금 확인까지 같은 순서로 기록하면 누락 여부를 사람이 기억하지 않아도 됩니다.

계약 확정부터 증빙 정리까지

1. 발행 예정 기록 생성: 계약 또는 작업 일정이 확정되면 인보이스 레코드를 먼저 만듭니다.
2. 거래처 조건 불러오기: 담당자, 지급 조건, 통화, 세금 처리 방식을 확인합니다.
3. 금액 검토: 공급가액, 세금, 총액, 계약금 또는 잔금 구분을 확인합니다.
4. 번호 부여와 발송: 고유 번호를 붙이고 PDF를 보낸 뒤 발송일과 전달 채널을 기록합니다.
5. 입금 예정 관리: 지급기한 전 확인할 항목을 별도 보기에 모읍니다.
6. 입금 처리: 실제 입금액, 입금일, 수수료, 부분 입금 여부를 기록합니다.
7. 증빙 마감: 인보이스 원본, 세금계산서, 입금 자료를 연결하고 월별 보기에 반영합니다.

실제 적용 사례

영상 편집 프리랜서 A씨는 월정액 고객 세 곳과 단발성 프로젝트를 함께 관리했습니다. 인보이스는 매번 제때 보냈지만, 통장에 입금된 금액과 이메일 발송 기록을 월말마다 다시 맞춰야 했습니다.

문제는 발행 여부가 아니었습니다. 한 거래처는 송금 수수료를 공제했고, 다른 거래처는 두 번에 나누어 입금했습니다. A씨는 총 청구액을 실제 입금액으로 덮어쓰면서 원래 미수금이 얼마였는지 알 수 없게 되었습니다.

이후 총 청구액, 실입금액, 입금일을 분리하고 ‘부분 입금’ 상태를 추가했습니다. 지급기한이 지났지만 실입금액이 총액보다 적은 항목만 모은 보기도 만들었습니다. 화려한 자동화는 없었지만 월말 확인 시간이 눈에 띄게 줄었습니다.

핵심은 입력량을 늘린 것이 아니라 금액을 덮어쓰지 않은 데 있었습니다. 기록은 많을수록 좋은 것이 아니라, 나중의 질문에 답할 수 있을 만큼 분리되어 있을 때 쓸모가 생깁니다.

보기 6개로 오늘 할 일만 남기는 방법

데이터베이스에 모든 거래를 넣었더라도 한 화면에 전부 펼쳐 두면 중요한 항목이 묻힙니다. 보기는 데이터를 복제하는 기능이 아니라 같은 기록을 목적별로 걸러 보는 창입니다.

업무용 보기 여섯 가지

보기 이름	필터 기준	확인할 행동
오늘 발행	발행 예정일이 오늘 이전, 발송일 비어 있음	금액 검토 후 발행
이번 주 입금 예정	입금 대기, 지급기한이 7일 이내	수신 여부와 지급 일정 확인
지급기한 초과	입금일이 비어 있고 지급기한이 지남	연락 이력 확인 후 후속 메시지
부분 입금	실입금액이 0보다 크고 총 청구액보다 작음	남은 금액과 다음 지급일 기록
이번 달 입금 완료	입금일이 이번 달	현금 유입과 증빙 확인
증빙 누락	입금 완료지만 증빙 묶음이 비어 있음	PDF, 세금계산서, 입금 자료 연결

총매출보다 미수금을 먼저 배치하세요

대시보드 맨 위에 이번 달 총매출을 크게 보여주고 싶어질 수 있습니다. 그러나 실제 운영에 더 도움이 되는 숫자는 아직 발행하지 않은 금액, 입금 대기 금액, 연체 금액입니다.

• 첫 번째: 발행 예정일이 지났지만 보내지 않은 건수
• 두 번째: 지급기한이 7일 이내인 입금 대기 금액
• 세 번째: 지급기한을 넘긴 미수금 합계
• 네 번째: 가장 오래된 연체 건의 지급기한

스마트폰에는 한 가지 보기만 남겨도 됩니다

모바일에서는 모든 속성을 보여줄 필요가 없습니다. 거래처, 총 청구액, 상태, 지급기한, 실입금액만 표시한 ‘빠른 입금 확인’ 보기를 별도로 만드세요.

입금 알림을 받은 뒤 이 보기에서 실입금액과 입금일만 입력하고, 증빙 정리는 데스크톱에서 마무리하면 이동 중 입력 실수를 줄일 수 있습니다.

반복 거래처와 버튼을 연결하는 실전 설계

같은 고객 정보를 인보이스마다 다시 입력하면 오타가 생기고 지급 조건도 조금씩 달라집니다. 반복 거래가 생기기 시작했다면 거래처 데이터베이스와 인보이스 데이터베이스를 분리해 연결하는 편이 좋습니다.

관계형과 롤업으로 거래처별 미수금 보기

관계형 속성은 서로 다른 데이터베이스의 항목을 연결하고, 롤업은 연결된 항목의 숫자나 개수를 집계합니다. 거래처와 인보이스를 연결하면 고객별 누적 청구액, 입금액, 미수금 또는 거래 건수를 계산할 수 있습니다.

• 거래처 데이터베이스: 회사명, 담당자, 이메일, 기본 지급 조건, 통화, 세금 처리 메모
• 인보이스 데이터베이스: 개별 청구 금액, 지급기한, 입금 상태, 증빙
• 관계형: 각 인보이스를 해당 거래처와 연결
• 롤업: 거래처별 총 청구액과 실입금액 합계 계산
• 수식: 총 청구액 합계에서 실입금액 합계를 빼 미수금 표시

월정액 고객은 반복 템플릿으로 미리 생성하세요

매달 같은 날짜에 같은 금액을 청구하는 거래처라면 반복 데이터베이스 템플릿으로 발행 예정 기록을 만들어 둘 수 있습니다. 다만 자동 생성된 항목은 곧바로 발행 완료로 처리하지 말고 반드시 검토 대기 상태로 시작하세요.

• 신규 거래처용: 지급 조건과 담당자 확인 항목을 포함
• 월정액 거래처용: 기본 금액과 매월 발행 예정일 포함
• 해외 거래처용: 통화, 환율 기준일, 송금 수수료 항목 포함
• 계약금·잔금용: 같은 프로젝트에 두 개의 청구 기록을 연결

버튼은 확인 후 실행하는 업무부터 줄이세요

Notion 버튼은 속성을 변경하거나 새 페이지를 만드는 반복 작업을 한 번의 클릭으로 묶을 수 있습니다. 버튼 자체는 모든 요금제에서 이용할 수 있지만 이메일 전송과 웹훅 등 일부 동작은 유료 요금제에서만 제공됩니다.

버튼 이름	권장 동작	사람이 확인할 내용
발행 완료	상태 변경, 발행일 입력, 원본 페이지 열기	금액, 지급기한, 수신인
입금 확인	입금 상태 변경, 처리일 입력	실입금액, 송금인, 수수료
다음 달 청구	새 인보이스 기록 생성	계약 유지, 금액 변경 여부
독촉 준비	담당자 정보와 원본 페이지 열기	최근 연락과 거래처 사정

버튼을 직접 설계하는 연습이 필요하다면 Notion 프롬프트 데이터베이스 구성법을 참고해 작업 목적, 입력값, 결과값을 먼저 문장으로 정의해 보는 것도 좋습니다.

조금 더 깊이 알고 싶다면

거래처와 인보이스를 분리하는 이유는 같은 정보를 반복 입력하지 않기 위해서입니다. 거래처의 담당자 이메일이나 기본 지급 조건이 바뀌었을 때 거래처 데이터베이스 한 곳만 수정하면 이후 인보이스에서 최신 정보를 확인할 수 있습니다.

다만 과거 발행 문서의 내용까지 자동으로 바뀌어서는 안 됩니다. 거래처 데이터는 현재 업무용 기준으로 사용하고, 이미 발송한 인보이스의 수신인과 지급 조건은 PDF 원본에 고정해 보관하세요.

입금 지연 관리와 흔한 실수 방지법

연체 관리는 지급기한이 지난 뒤 시작하는 일이 아닙니다. 거래처가 인보이스를 받았는지, 내부 지급 일정에 반영했는지를 지급기한 전에 확인하면 불필요한 지연을 줄일 수 있습니다.

지급기한 전후의 연락 기준

시점	확인할 내용	기록할 속성
지급기한 3일 전	인보이스 수신 여부와 예정 지급일	최근 연락일, 회신 메모
지급기한 당일	지급 일정에 변동이 있는지 확인	상태, 최근 연락일
3일 초과	미지급 사유와 확정 지급일 요청	연체 상태, 약속 지급일
장기 연체	추가 납품과 신규 작업 진행 여부 검토	위험 메모, 후속 조치

독촉 메시지는 감정의 온도를 낮추고 사실의 해상도를 높이는 편이 좋습니다. 인보이스 번호, 금액, 원래 지급기한, 확인을 요청하는 날짜를 짧게 적으세요.

부분 입금은 원래 청구액을 수정하지 않습니다

100만 원을 청구하고 60만 원이 들어왔다면 총 청구액은 100만 원으로 유지하고 실입금액에 60만 원을 적습니다. 남은 40만 원은 수식이나 별도 속성으로 표시합니다.

계약금과 잔금이 처음부터 나뉘어 있다면 청구 기록을 두 건으로 만드는 방법이 더 명확할 수 있습니다. 반대로 한 인보이스가 예기치 않게 나누어 입금된 경우에는 한 기록 안에서 실입금 합계를 관리하고 상세 내역을 메모나 별도 입금 데이터베이스에 남길 수 있습니다.

템플릿보다 먼저 막아야 할 실수 7가지

• 발행일만 입력하고 지급기한을 비워 두는 실수
• 총 청구액을 실입금액으로 덮어쓰는 실수
• ‘완료’ 하나로 발행, 입금, 증빙을 모두 처리하는 실수
• 거래처별 지급 조건을 확인하지 않고 같은 기한을 적용하는 실수
• 수정 인보이스를 새 번호나 버전 없이 원본 위에 저장하는 실수
• 달러, 엔화, 원화를 환산 기준 없이 합산하는 실수
• 예외가 많은 업무에 자동화를 과도하게 적용하는 실수

무료와 유료 자동화는 어디서 갈릴까

처음부터 유료 요금제를 결제할 필요는 없습니다. 속성, 필터 보기, 관계형, 롤업, 기본 템플릿과 단순 버튼만으로도 발행·입금·증빙 관리의 뼈대를 만들 수 있습니다.

무료 기능부터 검증할 순서

1. 필수 속성으로 인보이스 데이터베이스를 만듭니다.
2. 오늘 발행, 입금 대기, 연체 보기를 분리합니다.
3. 거래처 데이터베이스를 연결합니다.
4. 발행 완료와 입금 확인 버튼을 추가합니다.
5. 한 달 동안 실제 누락과 입력 시간을 기록합니다.

여기까지로 청구 누락과 미수금 문제가 해결된다면 유료 자동화가 없어도 충분합니다. 절약한 클릭 수보다 기록의 정확성이 먼저입니다.

유료 기능을 검토할 시점

데이터베이스 속성이 바뀔 때 자동으로 다른 작업을 실행하는 일반적인 데이터베이스 자동화는 유료 요금제에서 제공됩니다. 무료 사용자는 제한된 종류의 자동화나 템플릿에 포함된 기존 자동화를 사용할 수 있지만 편집 범위가 다를 수 있습니다.

• 상태 변경에 따라 반복 알림을 보내야 하는 경우
• 매달 수십 건의 고정 청구 기록을 생성해야 하는 경우
• 버튼 동작만으로는 후속 작업을 놓치는 경우
• 여러 데이터베이스에 같은 정보를 반복 입력하는 경우
• 자동화로 절약되는 시간이 요금보다 분명히 큰 경우

기본형·실속형·확장형 비교

운영 단계	권장 구성	적합한 사람	비용 전 확인사항
기본형	단일 데이터베이스, 필터 보기	월 청구 건수가 적은 초보자	속성 여섯 개로도 누락을 찾을 수 있는지
실속형	거래처 연결, 롤업, 기본 버튼	반복 고객이 있는 1인 사업자	중복 입력이 실제로 줄어드는지
확장형	유료 자동화, 외부 연동, 세분화된 데이터베이스	청구량이 많고 반복 작업이 뚜렷한 사업자	예외 거래와 오류 발생 시 복구 방법

요금제 기능은 바뀔 수 있으므로 결제 전에 현재 계정에서 필요한 동작을 직접 시험하고 공식 안내를 확인하세요. 특히 이메일 발송, 외부 서비스 연결, 권한 조건은 단순한 상태 변경 버튼과 다르게 취급될 수 있습니다.

월말 전에 확인할 세 가지 구멍

월말 점검은 매출 합계를 구경하는 시간이 아니라 기록에서 빠져나간 거래를 찾는 시간입니다. 발행 누락, 입금 누락, 증빙 누락 세 가지만 집중해도 대부분의 오류를 발견할 수 있습니다.

첫 번째 구멍: 업무는 끝났는데 청구 기록이 없는 건

프로젝트 데이터베이스나 일정표에서 이번 달 완료된 업무를 확인하고 인보이스 기록과 대조하세요. 계약이 끝났는데 발행 예정 레코드조차 없다면 가장 위험한 누락입니다.

• 완료 프로젝트 수와 생성된 인보이스 수 비교
• 월정액 고객의 이번 달 청구 기록 확인
• 추가 작업과 수정 비용이 인보이스에 반영됐는지 확인
• 계약금과 잔금 중 남은 청구가 있는지 확인

두 번째 구멍: 통장에는 들어왔지만 상태가 그대로인 건

통장 거래 내역과 입금 대기 보기를 나란히 놓고 대조하세요. 거래처명과 송금인명이 다르거나 여러 건을 합쳐 입금한 경우에는 자동 확인만으로 놓치기 쉽습니다.

• 입금자명이 거래처명과 다른 건
• 송금 수수료가 빠진 해외 입금
• 두 인보이스가 한 번에 입금된 건
• 부분 입금 후 상태가 입금 대기로 남은 건
• 입금일이 다른 달로 잘못 입력된 건

세 번째 구멍: 돈은 받았지만 증빙이 닫히지 않은 건

입금 완료 상태인데 증빙 묶음이 비어 있는 거래를 필터링하세요. PDF 원본, 세금계산서 처리 여부, 입금 자료, 수정 이력을 확인한 뒤 월 마감 상태로 전환합니다.

월말 체크 항목	완료 기준
발행 누락	완료된 모든 유상 업무에 청구 기록이 있음
입금 누락	통장 입금과 데이터베이스 실입금액이 일치함
증빙 누락	인보이스 원본과 관련 증빙이 연결됨
미수금	남은 금액과 다음 조치일이 기록됨
수정·취소	원본과 변경 이력이 함께 남아 있음
백업	월별 내보내기 또는 별도 저장본이 있음

내보내기 파일만으로 관계형 구조가 완전히 복구되지 않을 수 있으므로 중요한 PDF 원본과 계약 자료는 Notion 밖에도 보관하세요. 특히 단일 계정과 한 저장 위치에 모든 증빙을 몰아두는 방식은 피하는 편이 좋습니다.

자주 묻는 질문

견적서와 인보이스를 하나의 데이터베이스에서 관리해도 되나요?

거래 건수가 적다면 문서 종류 속성을 만들어 함께 관리할 수 있습니다. 다만 견적 승인 과정과 입금 추적 과정의 상태값이 크게 다르다면 데이터베이스를 분리하고 프로젝트 또는 거래처로 연결하는 편이 더 명확합니다.

거래처마다 부가세 포함 여부가 다르면 어떻게 구성하나요?

공급가액, 부가세, 총 청구액을 각각 분리하고 세금 처리 유형을 선택 속성으로 추가하세요. 단순히 ‘부가세 포함’이라는 메모만 남기면 총액이 바뀌었을 때 계산 근거를 찾기 어렵습니다. 구체적인 세무 처리는 거래 유형에 따라 공식 기준을 확인해야 합니다.

계약금과 잔금은 한 행에 기록해야 하나요?

각각 지급기한과 발행 문서가 다르다면 두 개의 인보이스 기록으로 나누는 방법이 좋습니다. 두 기록을 같은 프로젝트와 연결하면 전체 계약 금액과 각 청구 상태를 함께 볼 수 있습니다.

외화 인보이스와 원화 인보이스를 합산해도 되나요?

통화가 다른 금액을 그대로 더하면 의미 없는 합계가 됩니다. 원통화 청구액을 유지하고, 환율 기준일과 실제 원화 입금액을 별도로 기록하세요. 월별 합계를 낼 때는 어떤 환율과 날짜를 사용했는지 일관된 기준을 남겨야 합니다.

매달 같은 금액을 청구하는 고객은 자동 생성할 수 있나요?

반복 데이터베이스 템플릿이나 자동화를 활용할 수 있습니다. 다만 계약 종료, 단가 변경, 휴무월 같은 예외가 있으므로 생성된 기록은 ‘발행 예정’ 또는 ‘검토 필요’ 상태로 두고 사람이 확인한 뒤 발송하세요.

지급기한이 지나면 자동으로 이메일을 보내도 될까요?

기술적으로 가능한 환경이 있더라도 완전 자동 발송은 신중하게 설정해야 합니다. 이미 입금했지만 기록이 늦게 반영됐거나 거래처와 별도 합의가 있었을 수 있습니다. 자동으로 ‘독촉 필요’ 상태와 알림만 만들고, 발송 전 사람이 확인하는 구조가 안전합니다.

인보이스 PDF를 직접 올리는 것과 링크로 연결하는 것 중 무엇이 낫나요?

파일이 작고 한곳에서 확인하는 편의성이 중요하면 직접 첨부가 편합니다. 별도 클라우드 저장 규칙과 백업 체계가 있다면 링크 연결이 관리에 유리할 수 있습니다. 어느 방식을 선택하든 파일명, 접근 권한, 삭제 시 복구 방법을 정해 두세요.

무료 요금제에서도 연체 보기를 만들 수 있나요?

날짜, 상태, 입금일 속성과 필터를 이용하면 기본적인 입금 대기와 연체 보기를 만들 수 있습니다. 유료 기능을 검토하기 전에 지급기한이 지났고 입금일이 비어 있는 항목을 정확히 걸러낼 수 있는지 먼저 시험하세요.

회계 프로그램과 Notion에 같은 내용을 두 번 입력해야 하나요?

모든 항목을 복제할 필요는 없습니다. 회계 프로그램에는 세무와 장부 처리에 필요한 공식 정보를 두고, Notion에는 프로젝트, 발송, 지급기한, 연락, 미수금 조치처럼 업무 운영에 필요한 정보를 남기세요. 중복 입력 항목을 최소화하려면 각 도구의 기준 기록이 무엇인지 먼저 정해야 합니다.

오늘 20분 안에 청구 누락 보기 만들기

처음부터 완성형 템플릿을 만들려 하지 마세요. 오늘 필요한 것은 아름다운 대시보드가 아니라 놓친 청구를 한 건이라도 발견하는 작은 창입니다.

1. 5분: 새 데이터베이스에 거래처, 발행 예정일, 발송일, 지급기한, 총 청구액, 입금일을 만듭니다.
2. 5분: 실제 거래 세 건을 입력해 미발행, 입금 대기, 입금 완료 상태를 재현합니다.
3. 5분: 발행 예정일은 지났지만 발송일이 비어 있는 항목만 표시하는 보기를 만듭니다.
4. 5분: 매일 업무를 마치기 전 이 보기를 확인하도록 즐겨찾기나 첫 화면에 배치합니다.

이 보기가 제대로 작동하면 다음으로 지급기한 초과 보기와 증빙 누락 보기를 추가하세요. 템플릿은 한 번에 완성하는 물건이 아니라, 실제 거래가 지나간 자리에 필요한 표지판을 하나씩 세우는 시스템입니다.

최종 검토: 2026-07