Power Automate AI Builder 매입 청구서 승인 자동화

AI 업무 자동화

Power Automate AI Builder 매입 청구서 승인 자동화

청구서의 번호·거래처·합계를 먼저 읽되, 장부 등록은 신뢰도 검사와 재무 담당자의 승인을 모두 지난 뒤에만 실행하는 흐름입니다.

매입 청구서 한 장을 처리할 때 손이 가장 자주 가는 곳은 정해져 있다. 파일을 열고, 청구서 번호와 거래처, 합계와 지급기한을 찾아 옮긴다. 금액이 흐리거나 번호가 잘렸다면 다시 원문을 확인하고, 마지막에는 담당자에게 승인을 요청한다. 건마다 몇 분씩 걸리는 이 반복을 줄일 수는 있지만, 읽기 오류가 곧 지급 오류로 이어지는 업무를 ‘AI가 알아서 등록한다’로 설계하면 곤란하다.

여기서는 자동화의 끝을 지급이 아니라 승인된 청구서 목록 등록으로 제한한다. SharePoint의 수신 폴더에 들어온 파일을 Power Automate가 읽고, AI Builder가 핵심 필드와 신뢰도를 반환한다. 청구서 번호나 합계의 신뢰도가 0.65보다 낮으면 승인 요청조차 보내지 않고 검토함으로 돌린다. 기준을 통과해도 재무 담당자가 승인해야만 목록에 기록된다. 이 글은 2026년 7월 14일 Microsoft 공식 문서를 기준으로 재현 절차를 구성했으며, 실제 Microsoft 365 테넌트에 연결해 실행한 사용기는 아니다. 아래 값과 결과 화면은 검증용 예시다.

이번 자동화

AI Builder는 문서에서 값을 추출할 뿐이다. 계좌이체, ERP 전표 확정, 결제 승인, 거래처 마스터 변경은 흐름에 넣지 않는다. 출력은 ‘사람이 승인한 청구서의 SharePoint 목록 항목’까지다.

성공은 추출률이 아니라 잘못된 등록을 막았는지로 본다

이 흐름의 성공 조건은 OCR 결과가 채워졌다는 사실보다 좁다. 테스트 청구서로 다음 항목을 모두 확인해야 운영 후보가 된다.

• 수신 폴더 밖의 파일은 처리하지 않는다.
• 청구서 번호, 거래처, 청구일, 합계와 각 신뢰도를 원문과 대조할 수 있다.
• 필수 필드가 비었거나 지정 신뢰도보다 낮으면 장부용 목록에 아무 항목도 만들지 않는다.
• 기준을 통과한 문서도 승인 전에는 등록하지 않는다.
• 거절한 문서는 승인 문서와 다른 위치에 남고, 거절 의견을 추적할 수 있다.
• 같은 원본 파일을 재시도해도 장부용 항목이 두 개 생기지 않는다.

구분	자동화 전	자동화 후
입력	메일·메신저·폴더에 흩어진 청구서	SharePoint Incoming 폴더의 PDF·JPEG·PNG 한 건
처리	필드 눈으로 찾기, 옮겨 적기, 승인 요청	AI 추출 → 필수값·신뢰도 검사 → 사람 승인
출력	담당자마다 다른 기록	승인된 건만 InvoiceRegister 목록에 1행 등록
제외	별도 규칙이 없음	저신뢰 문서, 승인 거절, 중복 원본, 서비스 오류

계정과 비용은 흐름을 만들기 전에 확인한다

Microsoft 문서상 AI Builder를 실행하려면 Dataverse가 있는 Power Platform 환경과 사용할 수 있는 AI Builder 또는 Copilot 크레딧이 필요하다. 2025년 11월 1일 이후 AI Builder 체험판은 중단됐고, 신규 고객은 기존 AI Builder 용량 추가 기능을 새로 구매할 수 없다. 오래된 학습 문서에 남은 체험판 안내는 현재 비용 계획에서 제외했다.

준비 항목	필요 범위	운영 전 질문
Power Automate	클라우드 흐름 작성·실행 권한	개인 계정이 아니라 업무용 서비스 계정으로 소유권을 넘길 수 있는가
SharePoint	한 사이트의 문서 라이브러리와 두 목록에 읽기·쓰기	재무팀 외 사용자가 원본과 승인 기록을 볼 수 없는가
AI Builder	사전 빌드된 청구서 처리 모델	환경에 남은 크레딧과 월 예상 페이지 수를 관리자가 확인했는가
Approvals	지정 재무 담당자에게 승인·거절 요청	대리 승인과 부재 시 처리자를 조직 규정에 맞게 정했는가

2026년 7월 14일 미국 공식 가격표에는 Power Automate Premium이 연간 결제 기준 사용자당 월 15달러로 표시돼 있다. AI Builder의 청구서 분석은 페이지당 Copilot Credit 8개이며, 종량제 환산은 페이지당 0.08달러다. 기존 AI Builder 크레딧을 쓰는 환경이라면 페이지당 32크레딧을 사용한다. 따라서 한 페이지짜리 청구서 100건은 Copilot Credit 800개, 종량제 기준 8달러로 계산할 수 있다.

다만 이것은 문서 분석분만 계산한 값이다. Microsoft 365·SharePoint 라이선스, 재시도한 페이지, 여러 페이지짜리 파일, 세금과 환율은 별도다. Power Automate Premium에 포함된 월 5,000 AI Builder 크레딧도 2026년 11월 1일에 제거될 예정이며, 테넌트에서 다른 흐름과 공유한다. 실제 예산은 “무료로 몇 건”이라는 계산보다 Power Platform 관리 센터의 소비 보고서에서 잡아야 한다.

폴더 네 개와 목록 두 개부터 만든다

문서 라이브러리 이름을 Invoices로 만들고 그 안에 Incoming, NeedsReview, Approved, Rejected 폴더를 둔다. 처리 상태를 파일 이름에 덧붙이지 않는 이유는 재실행과 검색이 어려워지기 때문이다. 원본 이름은 유지하고 위치와 목록 상태로 구분한다.

InvoiceRegister 목록에는 다음 열을 만든다.

• SourceFileId: 원본 파일의 고유 식별자. 한 줄 텍스트 열로 만들고 고유 값 적용을 켜서 중복 저장을 막는다.
• InvoiceId, VendorName, InvoiceDate, DueDate, InvoiceTotal: 추출값
• ConfidenceInvoiceId, ConfidenceInvoiceTotal: 검토 근거
• ApprovalBy, ApprovalAt, ApprovalComment: 사람 승인 기록
• SourceLink: 원문을 다시 여는 링크

FlowErrorLog 목록은 오류 시각, SourceFileId, 실패한 단계, 흐름 실행 링크, 재처리 상태만 보관한다. 청구서 본문이나 계좌번호를 오류 메시지에 통째로 복사하지 않는다.

Power Automate에서는 여덟 단계만 잇는다

메뉴 이름은 영문 디자이너의 현재 표기를 함께 적었다. 한국어 화면에서는 번역명이 달라도 괄호 안 영문으로 검색하면 찾기 쉽다.

1. When a file is created (properties only) 트리거를 추가한다. 사이트와 Invoices 라이브러리를 고르고 Folder를 /Incoming으로 제한한다. 이 트리거는 속성만 반환하므로 문서 본문은 아직 읽지 않는다.
2. Get file content를 추가하고 트리거의 File identifier를 연결한다. 확장자가 PDF·JPEG·PNG가 아니면 NeedsReview로 보내고 종료한다.
3. Get items로 InvoiceRegister의 SourceFileId를 조회한다. 같은 값이 이미 있으면 중복 로그만 남기고 종료한다. 정확한 OData 필터 문자열은 사이트의 내부 열 이름을 확인한 뒤 디자이너에서 작성한다. 고유 열 설정은 동시에 들어온 중복 쓰기를 한 번 더 막는다.
4. Extract information from invoices를 추가하고 Invoice file에 2단계의 File content를 넣는다. 한 장짜리 파일로 시작한다면 Pages에 1을 지정한다. 페이지 범위는 비용과 성능에 영향을 주며, 하나의 범위에 서로 다른 청구서를 섞으면 안 된다.
5. 조건에서 Invoice ID, Vendor name, Invoice total이 비어 있지 않은지 본다. 이어 Confidence of invoice ID와 Confidence of invoice total이 각각 0.65 이상인지 확인한다. 하나라도 실패하면 승인 요청을 만들지 않고 파일을 NeedsReview로 이동한다.
6. Start and wait for an approval을 추가하고 Approval type은 Approve/Reject – First to respond로 둔다. 제목에는 거래처와 청구서 번호, Details에는 합계·청구일·지급기한·두 신뢰도, Item link에는 SharePoint 원본 링크를 넣는다. 계좌번호는 승인 본문에 복사하지 않는다.
7. Outcome이 Approve일 때만 InvoiceRegister에 항목을 만든다. 승인자, 승인 시각, 의견도 같은 행에 기록한 뒤 파일을 Approved로 이동한다. 이 단계 뒤에 결제 API나 ERP 전표 확정 작업을 붙이지 않는다.
8. Outcome이 Reject이면 등록 없이 파일을 Rejected로 옮기고 의견을 남긴다. 승인자는 이메일, Power Automate 승인 센터, 모바일 앱에서 응답할 수 있다.

0.65는 출발점이지 정답이 아니다

Microsoft 공식 예시에는 신뢰도 0.65보다 낮을 때 사용자 지정 모델로 넘기는 흐름이 나온다. 이 수치를 모든 청구서의 합격선으로 보장하지는 않는다. 거래처별 실제 샘플 20건 이상을 원문과 대조하고, 번호·합계처럼 위험한 필드는 더 높은 기준을 적용할 수 있다.

사전 빌드 모델은 한국어를 지원하고, JPEG·PNG·PDF를 받으며, 파일 크기는 최대 20MB다. 그러나 ‘한국어 지원’이 국내 모든 전자세금계산서 레이아웃의 정확도를 보장한다는 뜻은 아니다. 한 파일에 선명한 청구서 한 건을 넣고, 반복해서 낮은 신뢰도가 나오는 거래처 양식은 사용자 지정 문서 처리 모델이나 수동 검토 대상으로 분리한다.

가상 청구서 세 장으로 승인 전후를 확인한다

아래 값은 실제 처리 결과가 아니라 흐름을 검증하기 위한 가상 데이터다. 테스트용 문서에도 실제 계좌번호, 사업자등록번호, 거래처 연락처를 넣지 않는다.

테스트	추출 예시	기대 결과
A. 선명한 1페이지	IV-2026-0714-008 (0.92), 한별문구·가상 (0.89), 198,000원 (0.97)	승인 요청 생성. 승인 전 목록 0행, 승인 후 1행
B. 합계가 흐린 스캔	IV-2026-0714-009 (0.90), 합계 198,000원 (0.58)	승인 요청 없음. NeedsReview로 이동, 목록 0행
C. A 파일 재처리	동일 SourceFileId	새 승인과 새 목록 항목 없이 중복 로그만 기록

A 문서는 승인 메일을 받자마자 SharePoint 목록을 먼저 연다. 행이 아직 없다면 승인 경계가 지켜진 것이다. 승인 버튼을 누른 뒤에는 등록된 합계와 원문을 대조하고, 파일이 Approved 폴더로 이동했는지 본다. 다시 같은 파일 ID로 실행했을 때 행 수가 1에서 늘지 않아야 한다.

B 문서는 합계 텍스트가 그럴듯해도 신뢰도가 낮기 때문에 멈춰야 한다. AI가 반환한 값만 저장하면 오독을 정상값처럼 굳혀 버린다. 모델과 평가 경계를 함께 보는 이유는 [AI 뉴스룸] GPT-5.6 에이전트 전환에서 드러난 실무 변수의 평가기 사례와도 이어진다. 모델 이름보다 먼저 실패를 어디서 잡을지 정해야 한다.

오류는 원본을 남긴 채 멈춰야 복구할 수 있다

주요 작업을 Try Scope 안에 넣고, 별도의 Catch Scope를 만든다. Catch의 Run after는 Try가 실패하거나 시간 초과됐을 때만 실행되도록 설정한다. Catch에서는 FlowErrorLog에 파일 ID와 실패 단계, 실행 링크를 남기고 담당자에게 알린 뒤 Terminate로 종료한다. Microsoft도 Scope와 Run after를 이용한 try/catch 패턴, 일시적 오류에 대한 지수형 재시도, 명시적인 Terminate를 권장한다.

실패	확인	복구
NoCapacity·QuotaExceeded	환경의 AI Builder·Copilot Credit 할당과 소비 보고서	용량을 배정한 뒤 원본 한 건만 재실행한다.
필수 필드가 비어 있음	파일 선명도, 페이지 범위, 실제 청구서 여부	NeedsReview에서 사람이 수정하고 새 파일로 다시 올린다.
승인 후 목록 쓰기 실패	승인 기록과 SourceFileId 존재 여부	중복 검사 뒤 목록 쓰기 단계부터 재처리한다.
연결 계정 만료	SharePoint·Approvals 연결 소유자	업무용 계정으로 연결을 복구하고 테스트 폴더에서 1건만 확인한다.

긴급 중단은 흐름을 끄는 것부터 시작한다. 아직 Incoming에 있는 원본은 그대로 두고, 실패 실행을 무더기로 재시도하지 않는다. 잘못 등록한 목록 항목은 SourceFileId와 승인 기록을 대조해 사람이 취소 상태로 바꾸며, 원본 파일을 삭제하지 않는다. 이번 설계에는 지급 기능이 없으므로 자동화 중단이 곧 자금 이동 취소 문제로 번지지 않는다.

청구서가 외부 서비스로 새지 않도록 연결을 묶는다

AI Builder 공식 아키텍처 문서에 따르면 예측 시 사용한 이미지와 문서는 AI Builder에 지속 저장되지 않고, 입력·출력·학습 데이터는 다른 고객이나 OpenAI에 제공되지 않으며 기초 모델 학습에도 쓰이지 않는다. 그렇다고 데이터가 사라지는 것은 아니다. 원본은 SharePoint에 남고, 추출 필드와 승인 의견은 목록과 흐름 실행 기록에 남을 수 있다. 사이트 권한과 보존 기간을 재무 문서 정책에 맞춰야 한다.

• SharePoint와 AI Builder가 포함된 Dataverse 등 이 업무의 커넥터가 서로 다른 데이터 그룹으로 갈라지지 않았는지 확인한다.
• Dropbox, 개인 Gmail, HTTP, 커스텀 Webhook처럼 청구서를 밖으로 보낼 수 있는 커넥터는 이 흐름에 넣지 않는다.
• 흐름 소유 계정은 지정 사이트·라이브러리·목록만 읽고 쓸 수 있게 한다.
• API 키, 셸, 브라우저 자동 조작, 로컬 파일 쓰기, 결제 권한, 우회 권한, MCP, 장기 메모리는 사용하지 않는다.
• 무인 실행은 추출과 분류까지만 허용하고, 장부 등록 앞의 사람 승인은 제거하지 않는다.

첫 운영 주의 목표는 처리 건수가 아니라 수정 사유 수집이다. 20건을 원문과 대조해 청구서 번호, 합계, 거래처별 오독을 따로 세고, 저신뢰 검토함으로 제대로 빠졌는지 확인한다. 그 기록이 쌓인 다음에 임계값을 조정해야 한다. 자동 지급이나 ERP 확장은 그보다 뒤의 별도 프로젝트다.

출처와 확인 문서

• Microsoft Learn — Use the invoice processing prebuilt model in Power Automate
• Microsoft Learn — Invoice processing prebuilt AI model
• Microsoft Learn — Create and test an approval workflow with Power Automate
• Microsoft Learn — Manage approval requests in Power Automate
• Microsoft Learn — SharePoint connector reference
• Microsoft Support — Unique columns in SharePoint lists
• Microsoft Learn — AI Builder licensing and capability rates
• Microsoft Learn — End of AI Builder credits
• Microsoft — Power Automate pricing
• Microsoft Learn — AI Builder architecture and enterprise data protection
• Microsoft Learn — Administer AI Builder
• Microsoft Learn — Power Platform data policies
• Microsoft Learn — Employ robust error handling

가격, 크레딧 정책, 메뉴 이름과 지원 범위는 바뀔 수 있습니다. 실제 운영 전 각 링크와 테넌트 관리 센터의 현재 값을 다시 확인하세요.