송장 워크플로 자동화 체크리스트

송장 워크플로 자동화 체크리스트

8단계 점검 항목으로 송장 접수, 대조, 계정과목 지정, 승인, 예외 처리, 지급 준비 상태를 확인합니다.

청구서 승인 워크플로여기서 시작: 청구서 승인 워크플로

청구서가 납부되기 전에 확인해야 하는 8개의 통제

청구서 워크플로 자동화는 구조화된 접수, 검증, 일치, 코딩, 승인, 예외 해결 및 지불 준비 전달을 통해 하나의 청구서를 이동합니다. 아래의 컨트롤을 사용하여 재검토되어야 할 사항, 왜 중요하며 기록에 남아 있어야 하는 증빙 자료들을 확인하십시오.

전체 회계 결제 워크플로을 검토
01
송장 식별 정보AP 수입
검증
판매자, 청구서 번호, 청구서의 날짜, 결제 날짜, 통화, 하위 총액, 세금 및 총액이 있습니다.
중요한 이유
실종된 식별자는 복제 검사, 노화 및 하류 조화를 신뢰할 수 없게합니다.
증빙
출처 청구서, 유니컬 인 Faktura 참조, 캡처 된 총액 및 복제 확인 결과.
02
판매자 제어AP 또는 판매자 주 담당자
검증
판매자 기록, 송신 세부 사항, 세금 배경 및 은행 세부사항의 변경 사항은 확인됩니다.
중요한 이유
민감한 공급자 변경은 결제 방향을 전환하거나 세금 및 마스터 데이터 오류를 만들 수 있습니다.
증빙
활성 공급자 기록, 독립적인 변경 확인 및 지원 문신
03
구매 관련 정보요청자 또는 구매팀
검증
PO, 계약, 구매 요청, 신청자 또는 승인된 비PO 이유와 연결됩니다.
중요한 이유
승인자는 사업 의무를, 범위를 그리고 책임 있는 신청자를 파악해야 합니다.
증빙
PO, 계약, 요청, 수신 또는 문서화 된 비PO 근거.
04
경기 결과AP, 구매자 또는 수신 담당자
검증
가격, 양, 영수증, 세금, 화폐 및 용납률 결과는 적당할 경우 기록됩니다.
중요한 이유
부합은 소유의 예외가 되어야 하며, 일반 상태에서 사라지지 않아야 합니다.
증빙
일치 결과, 차이 수요, 용납 규칙, 예외 담당자 및 해상도
05
코딩회계 또는 예산 담당자
검증
법인, GL 계정, 부서, 비용 센터, 프로젝트, 할당 및 코딩 리뷰어는 완료되었습니다.
중요한 이유
승인은 잘못된 단체, 계정 또는 기간에 할당된 청구서를 수정할 수 없습니다.
증빙
코딩 값, 할당 세부 사항, 리뷰어, 검토 상태 및 수정 이력
06
승인 결정위촉된 승인자
검증
승인자, 임계수, 결정, 날짜, 의견, 반환 이유 및 검토된 청구서 버전은 보존됩니다.
중요한 이유
방어할 수 있는 결정은 누가 어떤 권위에 따라 어떤 버전을 승인했는지 보여야 합니다.
증빙
신분, 결정, 시간표, 의견, 임대 및 청구서 버전을 승인합니다.
07
예외 또는 유지예외 담당자
검증
그 이유, 담당자, 다음 행동, 유가 날짜, 증빙 자료 및 격상 상태는 눈에 띄습니다.
중요한 이유
소유되지 않은 지지는 승인 경로가 옳다고 하더라도 늦은 결제 위험을 초래합니다.
증빙
이유, 담당자 지정, 후속 날짜, 해결 증빙 자료 및 방출 결정.
08
결제 송금AP또는 재무
검증
지불 방법, 실행, 준비 상태, 발매 담당자, ERP 참조 및 최종 차단기가 알려져 있습니다.
중요한 이유
승인은 단지 결정일 뿐이고, 지불은 여전히 금융 시스템에 통제된 전달이 필요합니다.
증빙
준비 상태, 결제 실행 참조, 출시 담당자, ERP 참조 및 최종 결과.

다른 방법으로 순수한 청구서와 예외를

유용한 자동화는 일반적인 승인된 상태가 아닙니다. 그것은 일상적인 청구서를 부합, 지원되지 않은 비PO 청구서, 민감한 공급자 변경 또는 반환된 승인을 분리하는 결정입니다.

청구서 경로제어 테스트워크플로 경로보존된 증빙 자료
깨끗한 PO 청구서PO, 수신기, 가격, 양, 공급자, 통화 및 세금은 정책 용납 범위 내에서 있습니다.코딩 확인과 필요한 승인 수준으로 이동합니다.PO, 영수증, 일치 결과, 코딩 및 승인 결정.
가격 또는 양의 불균형청구서는 허용된 용납 범위를 초과하여 PO 또는 영수권에서 다릅니다.구매자, 요청자 또는 수신주에게 차이점을 붙여서 할당하십시오.차이가 있는 금액, 이유, 담당자의 반응, 수정 또는 받아들여진 예외
PO가 아닌 청구서구매 주문이 존재하지 않기 때문에 사업 목적과 권한은 다른 방법으로 확립되어야 합니다.요청자, 계약 또는 서비스 증빙 자료, 코딩 및 정책에 대한 특정 승인을 요구합니다.사업적 정당성, 출처 협정, 책임 있는 담당자 및 예외 이유.
복제 또는 공급자 데이터 위험청구서 참조, 금액, 은행 세부 사항 또는 공급자 변경은 민감한 검토를 유발합니다.정상적인 경로를 멈추고 독립적인 심사위원에게 기록을 보내십시오.복제 확인, 증빙 자료 변경, 검증 결과 및 검토자 신분.
반환된 승인승인자는 코딩, 증빙 자료, 정책적 맥락 또는 청구서의 자체가 불완전하기 때문에 결정을 내릴 수 없습니다.이전 결정의 이력를 삭제하지 않고 명명된 담당자에게 반환합니다.반환 이유, 요청된 수정, 재 제출 날짜 및 새로운 청구서 버전.

청구서 기록, 워크플로 제어 및 의사 결정 이력

Jodoo가 어떻게 청구서 기록과 구성 가능한 승인 제어 장치와 검토 가능한 의사 결정 추적을 결합하는지 확인하십시오. 연결된 청구서 앱을 열고, 필드, 단계, 승인자, 리마인더 및 대기열을 금융 프로세스에 적응하십시오.

승인은 지불이 아닙니다

이러한 랜드마크를 분리하여 승인된 청구서가 승인을 위한 줄을 따라 인증 금융 시스템 사이에 사라질 수 없도록 한다.

  1. 01검토 준비

    필요한 청구서, 공급자, 구매, 일치 및 코딩 컨텍스트가 완료되었습니다.

  2. 02Approved

    허가된 승인자는 검토 된 청구서 버전과 조건을 받아들였다.

  3. 03지불 준비

    해결되지 않은 유예가 남아있지 않으며 지불 맥락은 방출 검사를 통과하지 않았습니다.

  4. 04지불 및 조화

    금융 시스템은 실행, 참조 및 종료 결과를 확인합니다.

도구를 선택하기 전에 워크플로 계층을 테스트

유용한 청구서 자동화 제품은 출력 및 결제를 소유하는 회계 시스템을 대체하지 않고 제어 경로를 가시하게 해야 합니다.

  1. 01
    구성 가능한 수입

    재무가 청구서 필드, 필요한 증빙 자료, 상태 및 견해를 변경할 수 있습니까?

  2. 02
    예외 라우팅

    부합, 결실된 영수증, 복제품 및 민감한 공급자의 변경은 다른 소유의 경로를 따라갈 수 있습니까?

  3. 03
    승인 감사 경로

    모든 결정은 승인자, 청구서 버전, 의견, 시간표 및 환불 기록을 보관합니까?

  4. 04
    금융 시스템 간편화

    ERP 또는 회계 참조, 동기화 방향, 실패 담당자 및 조정 결과 explicit입니까?

  5. 05
    SLA 가시성

    AP는 고령화, 늦은 결정, 해결되지 않은 예외 및 유가 날짜에 다가오는 Faktura를 볼 수 있습니까?

송장 승인 및 AP 체크리스트 관련 질문

송장 승인은 AP 관리 추적표와 어떻게 다른가요?

송장 승인은 특정 송장을 검토 절차에 따라 라우팅합니다. 반면 AP 관리 추적표는 송장, 보류, 에이징, 담당자, 지급 준비 상태 전반에 걸친 더 넓은 백로그 관점을 재무팀에 제공합니다.

송장 승인 체크리스트에는 무엇이 포함되어야 하나요?

송장 식별 정보, 공급업체, 금액, 만기일, PO 또는 계약 참조, 코딩, 첨부 파일, 승인 결정, 보류 사유, 지급 준비 상태를 포함해야 합니다.

송장은 언제 보류해야 하나요?

필수 정보가 누락되었거나, 코딩이 완료되지 않았거나, 금액이 예상과 일치하지 않거나, 승인이 막혔거나, 공급업체 또는 지급 정보 검토가 필요한 경우 송장을 보류해야 합니다.

송장 승인 워크플로 템플릿 열기

Jodoo 템플릿을 미리본 뒤, 송장 코딩, 승인 대기열, 보류 사유, AP 상태, 지급 준비 상태를 팀의 프로세스에 맞게 조정하세요.

이 템플릿 미리보기