WEBVTT

00:00:00.940 --> 00:00:03.840
공급업체의 송장이 당신의 책상 위에 도착합니다.

00:00:04.100 --> 00:00:06.920
상품은 이미 창고에 입고되었거나 서비스는 이미 완료되었을 수 있지만

00:00:06.920 --> 00:00:08.920
결제 시계는 즉시 돌아가기 시작합니다.

00:00:09.120 --> 00:00:11.840
그렇다면 돈이 회사 밖으로 나가기 전에는 실제로 어떤 일이 벌어질까요?

00:00:12.000 --> 00:00:14.820
M365 FM에서 전해드리는 또 하나의 지식 나눔에 오신 것을 환영합니다.

00:00:15.000 --> 00:00:15.860
저는 미르 피터스이고

00:00:15.860 --> 00:00:19.020
오늘은 다이나믹스 365위 외상 매입금을 쉬운 언어로 살펴보겠습니다.

00:00:19.360 --> 00:00:22.600
이곳은 단순히 누군가가 청구서를 화면에 입력하기만 하는 곳이 아닙니다.

00:00:22.780 --> 00:00:25.400
각 청구서와 발송인, 회사가 구매하기로 합의한 내용

00:00:25.400 --> 00:00:28.200
그리고 대금 지급 여부를 확인하는 기업의 재무부서입니다.

00:00:28.200 --> 00:00:30.300
가장 간단한 정의를 말씀드리겠습니다.

00:00:30.540 --> 00:00:33.140
외상 매입금은 귀사가 이미 구매한 상품이나 서비스에 대해

00:00:33.140 --> 00:00:34.700
공급업체에 지불해야 할 금액입니다.

00:00:34.860 --> 00:00:37.180
대형 건물 안에 결제사무소라고 생각해보세요.

00:00:37.420 --> 00:00:39.960
청구서가 접수처에 도착하면 회사 기록과 대조하고

00:00:39.960 --> 00:00:43.440
승인 절차를 거친 뒤에야 비로소 결제 담당자에게 전달됩니다.

00:00:43.640 --> 00:00:47.220
우리는 공급업체 기록부터 최종 결제 완료 도장이 찍히는 경로까지 따라가 볼 것입니다.

00:00:47.420 --> 00:00:50.580
다이나믹스 365에서는 이를 결제, 세틀먼트라고 부릅니다.

00:00:50.780 --> 00:00:52.560
왜 외상 매입금이 존재하는 걸까요?

00:00:52.760 --> 00:00:55.740
사무용 가구를 판매하는 소규모 회사를 운영한다고 가정해보세요.

00:00:55.740 --> 00:00:58.200
책상을 판매하려면 먼저 책상이 필요합니다.

00:00:58.320 --> 00:01:03.680
또한 포장 박스, 청소 서비스, 인터넷 접속, 교체 부품, 그리고 아마도 배송업체도 필요할 것입니다.

00:01:03.860 --> 00:01:06.760
무언가를 주문할 때마다 모든 공급업체에 즉시 대금을 지불해야 한다면

00:01:06.760 --> 00:01:09.100
무언가를 구매하는 일이 금세 매우 어려워질 것입니다.

00:01:09.260 --> 00:01:12.240
대부분의 기업은 합의된 조건에 따라 먼저 구매하고 나중에 지불합니다.

00:01:12.440 --> 00:01:16.240
공급업체가 상품을 배송하거나 업무를 완료하면 청구서, 즉 그들의 고지서를 보냅니다.

00:01:16.400 --> 00:01:18.040
회사는 이제 그 금액을 빚진 상태이지만

00:01:18.040 --> 00:01:20.580
세부사항을 먼저 확인하지 않고 돈을 보내지는 않습니다.

00:01:20.580 --> 00:01:23.400
그 미지급 금액은 회사의 장부에 부채로 기록됩니다.

00:01:23.540 --> 00:01:27.220
부채라는 단어가 무서운 재무용어로 들릴 수 있지만 의미는 간단합니다.

00:01:27.400 --> 00:01:29.900
회사가 다른 누군가에게 갚아야 할 금액입니다.

00:01:30.120 --> 00:01:32.840
귀사가 사무용품 청구서를 받았지만 아직 지불하지 않았다면

00:01:32.840 --> 00:01:36.100
그 청구서는 결제가 완료될 때까지 외상 매입금에 속합니다.

00:01:36.340 --> 00:01:38.000
회사는 지금 당장은 현금을 보유하고 있지만

00:01:38.000 --> 00:01:40.100
지켜야 할 약속도 함께 가지고 있는 셈입니다.

00:01:40.300 --> 00:01:42.120
은행 계좌의 잔액은 건전해 보일지라도

00:01:42.120 --> 00:01:45.400
여전히 쌓여있는 미지급 청구서가 있을 수 있기 때문에 이는 중요합니다.

00:01:45.600 --> 00:01:47.580
재무팀은 양쪽을 모두 파악해야 합니다.

00:01:47.580 --> 00:01:52.020
은행에 얼마나 많은 현금이 있는지 그리고 그 현금 중 조만간 얼마나 나가야 하는지를 알아야 합니다.

00:01:52.140 --> 00:01:55.900
연결된 재무시스템이 없던 시절 이 업무는 종종 서류를 찾아 헤매는 일이 되곤 했습니다.

00:01:56.180 --> 00:01:59.860
송장이 우편으로 도착해 누군가의 책상 위에 놓이고 사내 메일을 통해 승인받는 동안

00:01:59.860 --> 00:02:02.420
또 다른 송장은 이메일 수신함에 방치될 수 있습니다.

00:02:02.640 --> 00:02:04.860
누군가는 같은 청구서를 스프레드 시트에 입력하고

00:02:04.860 --> 00:02:07.740
다른 사람은 회계 시스템에 입력하는 일이 벌어질 수 있습니다.

00:02:07.940 --> 00:02:09.620
이는 익숙한 문제들을 야기합니다.

00:02:09.860 --> 00:02:12.720
관리자가 승인 이메일을 놓치거나 청구서 지불이 늦어지거나

00:02:12.720 --> 00:02:16.880
공급업체가 이미 재무팀에 전달된 동일한 청구서를 다시 보내는 경우가 발생합니다.

00:02:17.060 --> 00:02:21.360
더 나쁜 경우 종이사본과 이메일 사본이 별개의 청구서처럼 보여서 두 번 지불될 수도 있습니다.

00:02:21.600 --> 00:02:25.000
다이나믹스 365는 회사에의 작업을 추적할 수 있는 단일 공간을 제공합니다.

00:02:25.200 --> 00:02:27.940
이 시스템은 회사의 부채를 기록하고 청구서 확인을 도우며

00:02:27.940 --> 00:02:30.620
청구서 수령부터 지불까지 명확한 경로를 유지합니다.

00:02:30.820 --> 00:02:33.840
그렇다고 모든 청구서가 사람의 검토 없이 처리된다는 의미는 아닙니다.

00:02:33.840 --> 00:02:36.300
재무팀은 여전히 문제가 있는 부분을 직접 판단하지만

00:02:36.300 --> 00:02:40.380
시스템은 서류를 찾아다닐 필요 없이 의사결정에 필요한 기록과 규칙을 제공합니다.

00:02:42.720 --> 00:02:47.060
이라는 용어도 함께 들을 수 있습니다. 이름은 거의 같지만 정반대의 의미를 가집니다.

00:02:47.260 --> 00:02:51.020
매입 채무는 공급업체에 갚아야 할 돈으로 회사에서 나가는 자금을 추적합니다.

00:02:51.280 --> 00:02:55.020
매출 채권은 고객이 지불해야 할 돈으로 회사로 들어오는 자금을 추적합니다.

00:02:55.260 --> 00:02:59.060
회사가 공급업체로부터 프린터를 구매하면 해당 청구서는 매입 채무로 처리됩니다.

00:02:59.240 --> 00:03:03.860
회사가 고객에게 책상을 판매하고 청구서를 보내면 그 고객 청구서는 매출 채권으로 처리됩니다.

00:03:03.860 --> 00:03:08.360
즉 매입 채무는 우리가 지불해야 할 금액을 매출 채권은 타인이 우리에게 지불해야 할 금액을 추적합니다.

00:03:08.520 --> 00:03:11.020
매입 채무의 목적은 매우 실용적인 결과를 지향합니다.

00:03:11.200 --> 00:03:14.260
합의된 날짜에 올바른 공급업체에 올바른 금액을 지불하는 것입니다.

00:03:14.480 --> 00:03:17.660
너무 빨리 지불하면 회사는 필요한 시점보다 일찍 현금을 잃게 됩니다.

00:03:17.940 --> 00:03:22.300
너무 늦게 지불하면 공급업체가 대금 지급을 독촉하거나 유리한 조건을 철회할 수 있습니다.

00:03:22.560 --> 00:03:28.580
잘못된 금액을 지불하면 나중에 이메일, 신용장, 많은 번거로움을 겪으며 실수를 바로 잡아야 합니다.

00:03:28.580 --> 00:03:36.680
따라서 청구서가 이 과정을 거치기 전에 다이나믹스 365는 공급업체가 누구인지, 그 관계에 어떤 규칙이 적용되는지 정확히 알아야 합니다.

00:03:36.880 --> 00:03:38.440
공급업체 기반 구축하기.

00:03:38.660 --> 00:03:43.300
다이나믹스 365가 단 하나의 청구서라도 처리하려면 먼저 누가 보냈는지 정확히 알아야 합니다.

00:03:43.480 --> 00:03:45.420
그때 필요한 것이 바로 공급업체 레코드입니다.

00:03:45.620 --> 00:03:48.920
레코드가 없으면 시스템은 누구에게 지불해야 할지, 어떤 규칙을 따라야 할지 알 수 없습니다.

00:03:49.160 --> 00:03:52.880
공급업체는 종이, 노트북, 예비 부품 같은 물리적인 물품을 공급할 수 있습니다.

00:03:52.880 --> 00:03:56.440
또한 회계나 소프트웨어 지원과 같은 서비스를 제공할 수도 있습니다.

00:03:56.660 --> 00:03:58.800
품목은 바뀌지만 역할은 동일합니다.

00:03:59.060 --> 00:04:01.260
이들은 우리 회사가 지불해야 할 대상입니다.

00:04:01.500 --> 00:04:04.880
공급업체 레코드를 다이나믹스 365네의 공급업체 파일이라고 생각하십시오.

00:04:05.620 --> 00:04:10.380
이 고대는 재무팀에 필요한 기본 정보가 저장되며, 이후에 모든 과정을 제어하는 규칙도 설정됩니다.

00:04:10.560 --> 00:04:15.600
공급업체의 이름, 주소, 연락처 정보를 입력하여 회사가 누구와 거래하는지 정확히 파악하게 됩니다.

00:04:15.840 --> 00:04:21.220
청구서와 결제에 사용되는 통화도 기록할 수 있는데, 이는 여러 국가의 공급업체와 거래할 때 매우 중요합니다.

00:04:21.220 --> 00:04:25.660
이제 결제 세부 정보로 넘어가서 공급업체 기록에 결제 조건과 결제 방법을 포함할 수 있습니다.

00:04:25.840 --> 00:04:29.380
화면상이 작은 필드처럼 보일 수 있지만, 이는 매우 실질적인 질문에 대한 답을 제공합니다.

00:04:29.560 --> 00:04:33.340
이 공급업체에는 언제 대금을 지급해야 할까요? 그리고 회사는 어떻게 대금을 송금해야 할까요?

00:04:33.480 --> 00:04:35.200
결제 조건은 만기일 규칙을 설정합니다.

00:04:35.400 --> 00:04:37.980
어떤 공급업체는 청구서 발행일로부터 30일 후 결제를 허용합니다.

00:04:38.160 --> 00:04:40.040
다른 곳은 14일 이내 결제를 원하기도 합니다.

00:04:40.240 --> 00:04:42.440
일부 업체는 조기 결제 시 할인을 제공하기도 합니다.

00:04:42.640 --> 00:04:46.900
다이나믹스 365는 기록된 조건을 사용하여 각 청구서의 만기일을 자동으로 계산합니다.

00:04:46.900 --> 00:04:50.860
따로 계약 내용을 기억할 필요가 없습니다. 이를 통해 일관성이 유지됩니다.

00:04:51.060 --> 00:04:55.460
5명이 담당자가 동일한 공급업체의 청구서를 처리하더라도 모두 같은 결제 규칙을 따르게 됩니다.

00:04:55.680 --> 00:04:59.560
누구도 대금 지급의를 확인하려고 예전 이메일을 뒤지거나 구매팀에 전화할 필요가 없습니다.

00:04:59.860 --> 00:05:02.280
결제 방법은 대금을 전달하는 방식을 설명합니다.

00:05:02.460 --> 00:05:06.280
회사는 한 공급업체에는 전자이체를 통해 다른 업체에는 수표로 결제할 수 있습니다.

00:05:06.500 --> 00:05:08.900
경우에 따라 약속어음을 사용할 수도 있습니다.

00:05:09.240 --> 00:05:14.740
다이나믹스 365에서는 필요한 경우 시스템 유형에 연결하면서 자체적 인결제 방법을 정의할 수 있습니다.

00:05:14.740 --> 00:05:17.360
일반적으로 기업은 여러 공급업체와 거래합니다.

00:05:17.560 --> 00:05:21.080
성장하는 기업이라면 수십, 수백, 심지어 수천 개의 업체와 거래할 수 있습니다.

00:05:21.300 --> 00:05:24.900
매번 처음부터 모든 설정을 만드는 것은 시간 낭비이며 실수를 초래할 수 있습니다.

00:05:25.140 --> 00:05:28.180
이것이 바로 다이나믹스 365에서 공급업체 그룹을 사용하는 이유입니다.

00:05:28.340 --> 00:05:31.560
공급업체 그룹은 동일한 재무규칙을 공유하는 공급업체들을 하나로 묶습니다.

00:05:31.800 --> 00:05:36.420
예를 들어 현지 사무용품 공급업체는 한 그룹으로, 해외 재고 공급업체는 다른 그룹으로 분류할 수 있습니다.

00:05:36.420 --> 00:05:42.680
이 그룹에는 거래 게시 방식, 결제 및 정산 처리, 공급업체 잔액보고 방식에 대한 공통 설정이 포함됩니다.

00:05:42.880 --> 00:05:45.500
각 공급업체에 대한 개별 기록은 그대로 유지됩니다.

00:05:45.720 --> 00:05:50.580
각 공급업체마다 고유한 이름, 주소, 결제 세부 정보 및 이력이 필요하기 때문에 중요합니다.

00:05:50.760 --> 00:05:55.760
공급업체 그룹은 공통된 시작점을 제공함으로, 재무팀에서 매번 똑같은 규칙을 다시 만들 필요가 없습니다.

00:05:56.060 --> 00:05:59.080
이면에는 공급업체 정기 프로필이라는 또 다른 요소가 있습니다.

00:05:59.400 --> 00:06:02.020
이름이 기술적으로 들리니 쉬운 용어로 설명해보겠습니다.

00:06:02.020 --> 00:06:07.600
정기 프로필은 공급업체 거래가 총계정 원장의 어디에 해당하는지 다이나믹스 365에 알려주는 지도와 같습니다.

00:06:07.880 --> 00:06:10.540
총계정 원장은 회사의 주요 재무계정 장부입니다.

00:06:10.740 --> 00:06:17.380
청구서가 게시될 때 다이나믹스 365는 회사가 지불해야 할 금액과 관련 비용이 어디에 속하는지 모두 기록해야 합니다.

00:06:17.620 --> 00:06:23.180
정기 프로필은 공급업체나 공급업체 그룹에 설정한 규칙을 사용하여 회계 항목의 공급업체 측면을 안내합니다.

00:06:23.420 --> 00:06:26.880
재무 담당자는 매번 기억에 의존해 원장 계정을 선택할 필요가 없습니다.

00:06:26.880 --> 00:06:32.780
대신 시스템이 설정된 규칙을 따름으로 불일치하는 항목이 줄어들고 재무팀은 공급업체 부채를 훨씬 명확하게 파악할 수 있습니다.

00:06:32.920 --> 00:06:35.740
또한 회사는 청구서가 도착하기 전에 지불 준비를 마칩니다.

00:06:35.960 --> 00:06:39.320
현금 및 은행 관리에서 공급업체 대금을 결제할 은행 계좌를 설정합니다.

00:06:39.540 --> 00:06:44.420
결제 붕괴를 통해 재무 담당자는 승인된 방법을 사용하여 결제를 준비하고 기록할 수 있는 작업 공간을 확보합니다.

00:06:44.620 --> 00:06:48.080
정리하자면 공급업체 레코드는 누가 대금을 받을지 식별합니다.

00:06:48.340 --> 00:06:54.040
지불 조건에 따라 기일이 결정되며 결제 방법과 은행 계좌에 따라 자금 지출 방식이 결정됩니다.

00:06:54.040 --> 00:06:59.900
이러한 규칙이 준비되면 청구서가 재무 부서에 접수되어 승인 절차를 시작할 수 있습니다.

00:07:00.420 --> 00:07:05.780
공급업체 레코드가 마련되면 다이나믹스 365는 누구에게 어떤 규칙으로 지불해야 하는지 알게 됩니다.

00:07:05.980 --> 00:07:08.340
그렇다면 실제 청구서가 도착하면 어떻게 될까요?

00:07:08.480 --> 00:07:10.900
때로는 재무 담당자가 직접 내용을 입력하기도 합니다.

00:07:11.060 --> 00:07:16.480
이는 이메일, 종이 서류, 공급업체 포털을 통해 청구서가 도착하여 누군가 시스템에 세부 정보를 입력해야 할 때 유용합니다.

00:07:16.480 --> 00:07:24.260
담당자는 공급업체를 선택하고 청구서 번호와 날짜를 입력한 뒤 청구서에 포함된 항목, 금액, 세금, 구매 주문 참조 번호를 추가합니다.

00:07:24.380 --> 00:07:26.540
청구서 번호는 주의 깊게 살펴봐야 합니다.

00:07:26.700 --> 00:07:30.760
이는 우리 회사가 아닌 공급업체에서 발급하는 번호이며 특정 청구서를 식별하는 데 도움이 됩니다.

00:07:30.960 --> 00:07:34.960
노스윈드 오피스 서플라이스에서 1200달러 청구서가 번호 N148로 도착하면

00:07:34.960 --> 00:07:39.780
다이나믹스 365는 해당 번호와 공급업체 레코드를 사용하여 중복 입력을 감지할 수 있습니다.

00:07:40.000 --> 00:07:42.040
청구 파일도 레코드와 함께 보관됩니다.

00:07:42.040 --> 00:07:47.640
pdf 청구서, 스캔한 문서 또는 증빙서류를 다이나믹스 365의 청구서 옆에 함께 저장할 수 있습니다.

00:07:47.840 --> 00:07:54.440
즉 레코드를 검토하는 담당자는 공유 메일함이나 서류함을 뒤질 필요 없이 숫자 뒤에 있는 문서를 바로 확인할 수 있습니다.

00:07:54.700 --> 00:07:57.720
청구서 물량이 많을 때는 전자방식으로 입력할 수 있습니다.

00:07:58.000 --> 00:08:01.920
다이나믹스 365는 데이터 엔터티를 통한 청구서 데이터 가져오기를 지원합니다.

00:08:02.140 --> 00:08:07.960
데이터 엔터티는 다른 시스템이 정보를 다이나믹스 365로 보내기 전에 작성하는 표준 양식이라고 생각하면 됩니다.

00:08:07.960 --> 00:08:14.640
예를 들어 외부 청구서 캡처 서비스는 청구서 헤더, 항목, 문서 청구 파일을 하나의 데이터 패키지로 보낼 수 있습니다.

00:08:14.860 --> 00:08:20.960
헤더에는 주요 청구 정보, 공급업체, 청구서 번호, 날짜, 통화, 총액, 구매 주문 참조 번호가 포함됩니다.

00:08:21.140 --> 00:08:22.820
항목은 청구 내역을 설명합니다.

00:08:23.040 --> 00:08:26.920
한 항목은 프린터 용지, 다른 항목은 토너, 또 다른 항목은 배송비일 수 있습니다.

00:08:27.140 --> 00:08:31.040
세부 정보를 분리해서 관리하면 재무 담당자가 자신이 승인하는 내용을 정확히 파악할 수 있습니다.

00:08:31.260 --> 00:08:33.280
세금 정보도 청구서와 함께 전달됩니다.

00:08:33.280 --> 00:08:38.160
다이나믹스 365는 회사가 청구서를 올바르게 기록할 수 있도록 세액 및 관련 세부 정보가 필요합니다.

00:08:38.320 --> 00:08:40.940
송장 검토를 진행하지 못하게 막는 몇 가지 요인이 있습니다.

00:08:41.180 --> 00:08:45.400
공급업체 누락, 유효하지 않은 날짜, 중복된 송장 번호, 또는 일치하지 않는 합계 금액 등이 있습니다.

00:08:45.640 --> 00:08:47.440
이러한 일시 중지는 회사를 보호합니다.

00:08:47.660 --> 00:08:51.420
공급업체 송장 정책은 송장이 귀사의 규정을 준수하는지 확인합니다.

00:08:51.660 --> 00:08:56.040
중복검사는 이미 기록된 동일한 공급업체 및 송장 번호처럼 친숙해 보이는 청구서를 찾아 냅니다.

00:08:56.240 --> 00:08:58.920
그 목적은 공급업체가 잘못을 저질렀다고 비난하려는 것이 아닙니다.

00:08:58.920 --> 00:09:01.640
공급업체는 송장이 도착했는지 확실하지 않아 다시 보낼 수 있습니다.

00:09:01.840 --> 00:09:04.380
담당자가 실수로 같은 pdf를 두 번 입력할 수도 있습니다.

00:09:04.600 --> 00:09:07.740
어느 경우 등 같은 청구서를 두 번 결제하는 것은 누구도 원치 않는 업무를 발생시킵니다.

00:09:07.900 --> 00:09:10.800
다이나믹스 365가 송장을 수락하면 다음 질문은 간단합니다.

00:09:10.980 --> 00:09:12.340
누가 이를 승인할 권한이 있나요?

00:09:12.460 --> 00:09:14.340
여기서 워크플로우, 워크플로우가 필요합니다.

00:09:14.500 --> 00:09:16.540
워크플로우는 시스템 내부의 승인 경로입니다.

00:09:16.780 --> 00:09:19.880
관리자에게 pdf를 이메일로 보내고 돌아오기를 기다리는 대신,

00:09:20.380 --> 00:09:24.780
다이나믹스 365는 귀사의 규칙에 명시된 담당자 나 역할에 송장을 전송합니다.

00:09:24.780 --> 00:09:29.200
각 조직은 자금 관련 의사결정을 어떻게 처리할지에 따라 해당 규칙을 결정합니다.

00:09:29.380 --> 00:09:31.900
소액의 일상적인 송장은 짧은 경로를 따를 수 있습니다.

00:09:32.120 --> 00:09:35.020
특정 금액 이상의 송장은 상급관리자의 승인이 필요할 수 있습니다.

00:09:35.240 --> 00:09:38.700
특정 부서와 관련된 청구서는 해당 부서 관리자에게 전달될 수 있습니다.

00:09:38.940 --> 00:09:43.540
재고 공급업체, 서비스업체, 도급업체 등 공급업체 유형에 따라 서로 다른 승인 경로를 만들 수도 있습니다.

00:09:43.760 --> 00:09:45.840
경로는 사람의 기억이 아닌 규칙을 따릅니다.

00:09:46.100 --> 00:09:48.400
이를 통해 승인 과정을 훨씬 쉽게 추적할 수 있습니다.

00:09:48.620 --> 00:09:53.240
재무부서는 송장이 검토되기 중인지, 승인되었는지, 아니면 추가 정보가 필요한지 확인할 수 있습니다.

00:09:53.240 --> 00:09:57.760
승인자는 청구서를 확인하고 자신의 부서 소관인지, 비용이 적절한지 판단할 수 있습니다.

00:09:57.980 --> 00:10:01.160
일부 송장은 모든 규칙을 충족하여 자동으로 다음 단계로 넘어갑니다.

00:10:01.320 --> 00:10:05.600
공급업체 정보가 알려져 있고, 가져온 세부 정보가 완전하며, 송장이 정책검사를 통과한 경우입니다.

00:10:05.780 --> 00:10:08.800
이러한 송장은 매번 사람이 똑같은 기본검사를 반복할 필요가 없습니다.

00:10:09.080 --> 00:10:10.600
다른 송장들은 예외 항목이 됩니다.

00:10:10.880 --> 00:10:12.560
공급업체 계정이 누락되었을 수 있습니다.

00:10:12.820 --> 00:10:14.520
송장 번호가 이미 존재할 수도 있습니다.

00:10:14.780 --> 00:10:16.600
가져온 항목에 오류가 있을 수도 있습니다.

00:10:16.860 --> 00:10:19.880
다이나믹스 365는 해당 송장들을 가져오기 실패 목록에 보관하여,

00:10:19.880 --> 00:10:24.200
재무 담당자가 오류 메시지를 확인하고, 보류 중인 송장을 생성하기 전에 문제를 수정할 수 있게 합니다.

00:10:24.360 --> 00:10:26.820
검토 과정에서도 원본 문서는 여전히 중요합니다.

00:10:27.020 --> 00:10:30.360
다이나믹스 365는 송장 페이지에 첨부 파일 뷰어를 포함하고 있어,

00:10:30.780 --> 00:10:34.160
재무 담당자가 수정 중인 기록바로 옆에서 송장 이미지를 확인할 수 있습니다.

00:10:34.400 --> 00:10:39.600
공급업체가 원본 청구서에 6천이라고 입력했는지, 8천이라고 입력했는지 확인하기 위해 화면을 전환할 필요가 없습니다.

00:10:39.880 --> 00:10:41.880
자동화는 일상적인 업무 흐름을 처리합니다.

00:10:42.160 --> 00:10:43.420
사람은 질문을 처리합니다.

00:10:43.640 --> 00:10:45.840
승인은 적절한 사람이 송장 진행에 동의했음을 확인해주지만,

00:10:45.840 --> 00:10:49.480
공급업체가 주문하거나 수령 한 항목 그대로 청구했음을 아직 증명하는 것은 아닙니다.

00:10:49.620 --> 00:10:51.980
이를 위해 다이나믹스 365는 서류를 대조합니다.

00:10:52.180 --> 00:10:53.920
송장 일치, 인보이스 매칭입니다.

00:10:54.100 --> 00:10:57.540
회사가 주문한 내용을 확인하고 승인하는 과정은 담당자가 송장을 검토했음을 입증합니다.

00:10:57.720 --> 00:10:59.580
하지만 일치 기능은 다른 질문에 답합니다.

00:10:59.780 --> 00:11:02.820
송장 내용이 회사가 실제로 구매하기로 합의한 내용과 일치하는가?

00:11:02.960 --> 00:11:07.180
구매가 구매 주문서로 시작되면 다이나믹스 365는 대조할 수 있는 기록을 갖게 됩니다.

00:11:07.180 --> 00:11:10.100
구매 주문서는 회사의 주문 점표라고 생각하면 됩니다.

00:11:10.340 --> 00:11:14.180
여기에는 공급업체, 요청 품목, 수량, 가격 및 조건이 기록됩니다.

00:11:14.180 --> 00:11:17.140
청구서가 도착하기 전에 구매 부서에서 주문서를 작성합니다.

00:11:17.300 --> 00:11:18.340
이게 왜 중요할까요?

00:11:18.520 --> 00:11:21.380
구매 주문서는 송장이 도착하기 전에 합의된 내용을 포착하기 때문입니다.

00:11:21.560 --> 00:11:24.420
주문서가 없으면 재무 담당자는 공급업체 이름으로 된 청구서만 보게 됩니다.

00:11:24.620 --> 00:11:27.740
주문서가 있으면 공급업체의 청구 금액을 원래 요청과 비교할 수 있습니다.

00:11:27.960 --> 00:11:30.460
물리적 상품의 경우 중요한 또 다른 기록이 있습니다.

00:11:30.760 --> 00:11:33.260
배송이 도착하면 참고팀이 제품 수령증을 기록하며

00:11:33.260 --> 00:11:38.020
이는 다이나믹스 365 내에서 상품이 회사에 도착했음을 입증하는 수량 포함 증거가 됩니다.

00:11:38.280 --> 00:11:42.240
모든 항목이 완벽하다는 뜻은 아니지만 해당 주문에 대해 수령된 내용이 기록됩니다.

00:11:42.240 --> 00:11:44.720
회사가 사무용 위자 10개를 주문한다고 가정해보겠습니다.

00:11:45.040 --> 00:11:47.520
구매 주문서에는 합의된 가격으로 위자 10개가 명시되어 있지만

00:11:47.520 --> 00:11:51.740
트럭이 도착했을 때 창고에서 확인한 수량은 8개뿐이며 나머지 2개는 105더 상태입니다.

00:11:51.920 --> 00:11:54.340
입고팀은 8개에 대한 제품 수령증을 개시합니다.

00:11:54.560 --> 00:11:56.420
그 후 공급업체는 위자 10개에 대한 송장을 보내는데

00:11:56.420 --> 00:12:00.500
이는 마지막 2개가 배송되기 전에 전체 주문에 대해 청구한 것으로 공급업체 입장에서는 맞을 수 있습니다.

00:12:00.700 --> 00:12:02.920
하지만 이제 귀사의 기록에는 차이가 발생합니다.

00:12:03.140 --> 00:12:05.520
10개 주문, 8개 수령, 10개 청구,

00:12:05.700 --> 00:12:09.180
다이나믹스 365는 송장일치를 통해 이러한 차이를 포착할 수 있습니다.

00:12:09.180 --> 00:12:12.020
양방향 일치는 구매 주문서와 공급업체 송장을 비교하여

00:12:12.020 --> 00:12:15.220
청구 금액이 가격 및 수량 측면에서 주문서와 일치하는지 확인합니다.

00:12:15.380 --> 00:12:19.020
이는 원래 주문서를 확인하는 것만으로 충분한 통제가 가능한 구매에 적합합니다.

00:12:19.220 --> 00:12:23.120
이는 공급업체가 더 높은 가격이나 주문보다 많은 수량을 청구하는 경우를 잡아내지만

00:12:23.120 --> 00:12:25.800
구매 주문서와 송장이라는 두 가지 기록만 비교하므로

00:12:25.800 --> 00:12:27.920
상품이 실제로 도착했는지는 확인하지 않습니다.

00:12:28.120 --> 00:12:30.520
3방향 일치는 여기에 제품 수령증을 추가합니다.

00:12:30.760 --> 00:12:33.200
따라서 다이나믹스 365는 이제 구매 주문서,

00:12:33.520 --> 00:12:35.560
제품 수령증, 송장을 함께 비교합니다.

00:12:35.560 --> 00:12:40.600
위자 사례에서 시스템은 쉽게 주문, 8개 수령, 쉽게 청구라는 내역을 확인합니다.

00:12:40.740 --> 00:12:44.860
그리고 그 차이는 송장을 그대로 처리하지 않고 일시 정지하는 이유가 됩니다.

00:12:45.140 --> 00:12:48.920
재고, 장비 또는 대량의 물리적 상품을 구매하는 기업의 경우

00:12:48.920 --> 00:12:53.820
이 검사는 도착하지 않은 품목이나 수령한 것보다 많은 금액을 지불하지 않도록

00:12:53.820 --> 00:12:55.780
재무부서의 통제력을 강화해줍니다.

00:12:55.960 --> 00:12:57.740
구매부서가 합의 내용을 확인합니다.

00:12:57.940 --> 00:13:01.600
입고 부서는 물품 수령을 확인하고 공급업체는 송장을 통해 대금을 청구합니다.

00:13:01.800 --> 00:13:04.140
아, 이 세 가지 기록은 모두 일치해야 합니다.

00:13:04.140 --> 00:13:07.000
실제 업무에서는 작은 차이가 발생하기 마련입니다.

00:13:07.160 --> 00:13:08.840
가격은 반올림 때문에 달라질 수 있고,

00:13:09.240 --> 00:13:11.980
공급업체는 허용된 범위 내에서 수량을 약간 조정할 수 있습니다.

00:13:12.220 --> 00:13:13.960
사소한 차이로 인해 송장 처리가 중단된다면,

00:13:14.360 --> 00:13:17.200
재무팀은 사소한 문제를 해결하는 데 너무 많은 시간을 허비하게 될 것입니다.

00:13:17.360 --> 00:13:21.820
따라서 다이나믹스 365를 통해 회사는 일치 정책과 허용 오차 한도를 설정할 수 있습니다.

00:13:22.020 --> 00:13:24.100
허용 오차는 허용 가능한 차이를 의미하며,

00:13:24.500 --> 00:13:29.640
회사는 가격, 수량, 합계 또는 관련 비용에 대해 수용할 금액이나 비율을 직접 결정합니다.

00:13:29.640 --> 00:13:32.580
허용 한도 내의 항목은 회사의 규칙에 따라 자동으로 처리되고,

00:13:32.860 --> 00:13:34.960
한도를 초과하는 항목은 검토를 위해 표시됩니다.

00:13:35.120 --> 00:13:36.660
그 한도는 회사가 결정합니다.

00:13:36.900 --> 00:13:39.080
기업은 저렴한 사무용품의 작은 차이는 허용하더라도,

00:13:39.440 --> 00:13:41.960
고가의 기계 장비에는 훨씬 엄격한 한도를 설정할 수 있습니다.

00:13:42.200 --> 00:13:44.500
시스템은 무엇이 합리적 인지 판단하지 않습니다.

00:13:44.720 --> 00:13:46.380
재무 및 구매 부서에서 규칙을 정하면,

00:13:46.800 --> 00:13:49.240
다이나믹스 365가 이를 일관되게 적용합니다.

00:13:49.440 --> 00:13:51.480
이는 재무팀의 업무 방식을 변화시킵니다.

00:13:51.660 --> 00:13:53.740
문제가 없는 모든 송장을 일일이 확인하는 대신,

00:13:54.060 --> 00:13:55.560
예외적인 사례에 집중할 수 있게 됩니다.

00:13:55.560 --> 00:13:58.080
가격이 변경되었거나, 영수증이 누락되었거나,

00:13:58.400 --> 00:14:00.460
수량이 맞지 않는 송장을 조사하는 것처럼 말이죠.

00:14:00.600 --> 00:14:02.200
정상적인 송장은 규칙에 따라 처리되지만,

00:14:02.560 --> 00:14:04.740
담당자는 의사결정이 필요한 부분에만 집중할 수 있습니다.

00:14:04.980 --> 00:14:06.960
그것이 바로 일치 작업의 진정한 가치입니다.

00:14:07.160 --> 00:14:08.720
시스템은 일상적인 검사를 담당하고,

00:14:09.080 --> 00:14:10.860
사람은 판단이 필요한 문제를 처리하는 방식입니다.

00:14:11.040 --> 00:14:12.960
이는 시스템이 판단을 대신하는 것이 아닙니다.

00:14:13.120 --> 00:14:15.800
일상적인 확인 작업과 실제 해결이 필요한 문제를 분류하는 것입니다.

00:14:16.000 --> 00:14:17.600
한 가지 혼동하기 쉬운 점이 있습니다.

00:14:17.880 --> 00:14:21.920
표준 다이나믹스 365일치 기능은 2방향 및 3방향 일치를 지원합니다.

00:14:21.920 --> 00:14:28.000
검사 기록 추가와 같은 4방향 일치가 필요한 경우에는 사용자 지정이나 별도의 솔루션을 통해 추가 작업이 필요합니다.

00:14:28.140 --> 00:14:30.080
결국 일치 작업의 역할은 명확합니다.

00:14:30.320 --> 00:14:36.340
네, 공급업체의 청구서와 회사의 구매 및 입고 기록을 비교하여 대금 지급 전 차이점을 찾아내는 것입니다.

00:14:36.560 --> 00:14:40.600
송장이 검토와 일치 확인을 통과하면 회사가 지급해야 할 채무가 되며,

00:14:40.720 --> 00:14:44.040
이를 바탕으로 공급업체의 대금을 지급하고 장부를 정리합니다.

00:14:44.260 --> 00:14:49.060
송장이 회사의 필수 검사 과정을 통과하면 다이나믹스 365에서 이를 정기할 수 있습니다.

00:14:49.060 --> 00:14:51.620
정기는 송장이 공식 재무 기록이 됨을 의미하며,

00:14:52.040 --> 00:14:56.820
회사는 공급업체에 지급해야 할 금액을 기록하고 대금이 청산될 때까지 미지급 상태로 표시합니다.

00:14:56.980 --> 00:15:00.060
송장 처리가 준비되었다고 해서 즉시 자금이 나가는 것은 아닙니다.

00:15:00.240 --> 00:15:03.660
재무팀은 대금 지급 실행 시 어떤 송장을 먼저 지급할지 결정해야 합니다.

00:15:03.860 --> 00:15:07.620
다이나믹스 365는 지급 제한 기능을 통해 만기된 송장을 확인하고,

00:15:08.140 --> 00:15:11.340
회사가 설정한 규칙에 따라 이번 실행에 포함할 항목을 제한합니다.

00:15:11.600 --> 00:15:14.660
지급 제한은 담당자가 검토하는 시작 단계의 목록일 뿐입니다.

00:15:14.660 --> 00:15:17.460
예를 들어 이번 주에 만기가 되는 공급업체 청구서가 있는 반면,

00:15:17.780 --> 00:15:20.320
다른 청구서는 약정 조건에 따라 이달 말까지 기다릴 수 있습니다.

00:15:20.500 --> 00:15:26.200
재무팀은 제한된 청구서를 확인하고 필요한 경우 항목을 추가하거나 삭제한 다음 지급 점표를 준비합니다.

00:15:26.400 --> 00:15:29.960
이런 방식으로 지급이 분산되지 않고 그룹화되어 관리됩니다.

00:15:30.200 --> 00:15:33.140
지급 점표를 회사의 지급 워크시트라고 생각하십시오.

00:15:33.300 --> 00:15:37.560
여기에는 회사가 보낼 공급업체 지급 목록, 금액, 지급 세부 정보가 나열됩니다.

00:15:37.760 --> 00:15:40.800
재무 담당자는 공유 기록 없이 청구서 하나하나를 따로 보내는 대신,

00:15:41.140 --> 00:15:43.340
이를 사용하여 관리 가능한 지급 배치를 준비합니다.

00:15:43.340 --> 00:15:45.080
자금은 어떻게 빠져나가나요?

00:15:45.220 --> 00:15:48.240
이는 공급업체와 회사의 설정된 지급 방식에 따라 다릅니다.

00:15:48.440 --> 00:15:55.120
다이나믹스 365를 사용하면 회사가 자체 지급 방식을 만들고 수표, 전자지급, 약속어음과 같은 지급 유형에 연결할 수 있습니다.

00:15:55.340 --> 00:15:56.740
수표는 익숙한 방식입니다.

00:15:56.980 --> 00:15:59.820
전자지급은 회사의 은행 프로세스를 통해 자금을 보냅니다.

00:16:00.020 --> 00:16:03.480
약속어음은 합의된 조건에 따라 지급하겠다는 공식적인 약속을 기록합니다.

00:16:03.720 --> 00:16:05.620
모든 기업이 모든 방식을 사용하는 것은 아니지만,

00:16:06.040 --> 00:16:09.040
다이나믹스 365는 회사가 사용하는 경로를 기록할 방법을 제공합니다.

00:16:09.040 --> 00:16:12.420
각 지급 방식은 또한 올바른 회사 은행 계좌를 가리켜야 합니다.

00:16:12.580 --> 00:16:18.240
기업은 서로 다른 법인, 통화 또는 지급 목적에 따라 별도의 계좌를 보유할 수 있으므로 이러한 연결은 중요합니다.

00:16:18.440 --> 00:16:22.440
재무팀이 지급을 준비할 때 시스템은 자금이 나갈 은행 계좌를 알아야 합니다.

00:16:22.660 --> 00:16:26.180
그렇지 않으면 담당자가 잘못된 계좌에서 지급을 생성할 수도 있습니다.

00:16:26.460 --> 00:16:28.180
지급 시기 또한 주의가 필요합니다.

00:16:28.420 --> 00:16:32.700
만기일 이후에 지급하면 독촉, 분쟁 또는 공급업체와의 관계약화로 이어질 수 있습니다.

00:16:32.700 --> 00:16:36.760
너무 일찍 지급하면 회사가 자금을 지출할 필요가 없는 시점에 현금이 유출됩니다.

00:16:36.960 --> 00:16:43.780
다이나믹스 365는 청구서 만기일을 계속 표시하여 재무팀이 각 공급업체와 합의한 조건에 맞춰 지급을 계획할 수 있게 하며,

00:16:44.300 --> 00:16:46.540
자금이 나갈 때 더 많은 통제권을 제공합니다.

00:16:46.720 --> 00:16:49.680
다이나믹스 365는 간단한 질문에 답해야 합니다.

00:16:49.880 --> 00:16:52.020
그 지급으로 어떤 청구서를 결제했나요?

00:16:52.180 --> 00:16:53.260
정답은 정산입니다.

00:16:53.520 --> 00:16:57.300
정산은 지급을 특정 공급업체 청구서 또는 결제 대상 청구서와 연결합니다.

00:16:57.520 --> 00:17:00.320
영수증을 청구서와 대조하여 처리하는 것으로 생각하십시오.

00:17:00.320 --> 00:17:03.860
정산이 없으면 회사는 동일한 공급업체 계정에서 청구서와 지급내역을 볼 수는 있어도,

00:17:04.260 --> 00:17:06.640
두 항목이 서로 관련되어 있다는 명확한 기록이 없을 수 있습니다.

00:17:06.840 --> 00:17:10.380
전액 지급은 청구서 전체를 정산하지만, 비즈니스가 항상 그렇게 깔끔하게 돌아가지는 않습니다.

00:17:10.540 --> 00:17:13.660
회사는 청구서 금액 중 일부만 먼저 지급하고, 나머지는 나중에 지급할 수도 있습니다.

00:17:13.880 --> 00:17:18.980
정산은 부분 지급을 기록하고, 잔액을 열어두어 재무팀이 공급업체에 여전히 지불해야 할 금액을 정확히 파악할 수 있게 합니다.

00:17:19.240 --> 00:17:22.020
이러한 가시성은 정확한 공급업체 잔액관리에 필수적입니다.

00:17:22.260 --> 00:17:24.520
하나의 지급으로 여러 청구서를 처리할 수도 있습니다.

00:17:24.520 --> 00:17:29.200
예를 들어, 한 기업이 같은 공급업체로부터 받은 5개의 미결제 청구서를 단일 전자결제로 지급할 수 있습니다.

00:17:29.360 --> 00:17:32.980
결제, 세틀먼트, 기능은 그 하나의 지출 금액을 각각의 청구서와 연결해 처리합니다.

00:17:33.160 --> 00:17:39.300
지급액이 모든 청구서 금액을 완전히 충당하지 못하더라도, 미결제 잔액은 명확하게 유지되며 혼란스러운 총액 속에 사라지지 않습니다.

00:17:39.480 --> 00:17:44.320
이는 추적 가능한 기록을 생성하며, 청구서의 승인 과정부터 일치 결과까지 전 과정을 확인할 수 있습니다.

00:17:44.520 --> 00:17:49.160
전월에 준비된 결제 내역을 확인하고, 해당 결제가 공급업체의 잔액을 어떻게 정산했는지 살펴보세요.

00:17:49.160 --> 00:17:55.000
자금 지출 이유에 대한 문의가 들어와도, 재무팀은 이메일이나 은행 명세서를 뒤져가며 상황을 재구성할 필요가 없습니다.

00:17:55.260 --> 00:17:59.240
프로세스가 다이나믹스 365위 여러 페이지에 걸쳐 나타날 수 있지만,

00:17:59.940 --> 00:18:04.480
각 기록은 하나의 관리된 흐름, 즉 연결된 매입 채무 전체 그림으로 이어집니다.

00:18:04.660 --> 00:18:07.540
사무용품에 대한 청구서를 하나 받았다고 가정해봅시다.

00:18:07.720 --> 00:18:13.220
공급업체 기록에는 결제 규칙이 담겨 있고, 가져온 청구서는 문서 자체는 물론 상세 내역까지 포함합니다.

00:18:13.440 --> 00:18:15.300
구매부서는 구매 주문서를 제공합니다.

00:18:15.300 --> 00:18:19.600
입고 부서는 입고 내역을 제공하여 일치 프로세스가 비교할 수 있는 실질적인 기록을 갖추게 합니다.

00:18:19.740 --> 00:18:24.000
이제 내부적으로는 정기 프로필, 포스팅 프로파일, 이 부채와 비용을 올바른 총계정 원장 계정으로 처리합니다.

00:18:24.140 --> 00:18:28.700
현금 및 은행 관리 기능은 어떤 결제 수단을 사용할지, 어떤 은행 계좌에서 자금을 이체할지 제어합니다.

00:18:28.940 --> 00:18:34.000
청구 파일은 거래 내역에 그대로 남아있으므로, 나중에 언제든 원본 청구서를 불러와 검증할 수 있습니다.

00:18:34.240 --> 00:18:37.080
자동화가 재무팀의 판단을 대신하는 것은 아닙니다.

00:18:50.340 --> 00:18:50.800
열기

00:18:50.800 --> 00:19:10.200
열기

00:19:10.200 --> 00:19:10.740
열기

00:19:10.740 --> 00:19:25.980
열기

00:19:25.980 --> 00:19:27.840
열기

00:19:28.620 --> 00:19:30.420
열기

00:19:30.420 --> 00:19:33.420
열기

00:19:33.480 --> 00:19:37.980
열기