솔루션 핸드북
설정, Jodoo 필드, 검증 레코드, 배포 메모를 포함한 Make 송장 예외 검토 루프 계획 가이드입니다.
핸드북 열기MAKE + JODOO
Make와 Jodoo를 사용해 송장 예외 검토를 실행하고, 예외 유형, 보류 사유, 지급 준비 상태, 배정된 검토자, 예산 담당자, 권장 해결 방안, 우선순위를 반환한 뒤, 결과를 추적 가능한 Jodoo 레코드에 저장합니다.
영상 안내
영상에서는 Atlas Packaging Co.의 INV-2026-1048이 PO 금액 불일치와 입고 확인 누락 상태로 워크플로에 들어오고, 이후 Jodoo가 운영 레코드를 저장하는 과정을 보여줍니다.
Atlas Packaging Co.의 INV-2026-1048이 PO 금액 불일치와 입고 확인 누락 상태로 워크플로에 들어옵니다.
워크플로는 느슨한 문단 대신 예외 유형, 보류 사유, 지급 준비 상태, 배정된 검토자, 예산 담당자, 권장 해결 방안, 우선순위를 명시적으로 유지합니다.
테스트 실행은 검토 결과를 Jodoo로 전송하고 브리지로부터 Jodoo 데이터 ID를 받습니다.
공개 검증본은 Make의 Run once 모드를 사용하므로, 캡처된 스크린샷에서 시나리오 기록의 webhook 번들, 모듈 버블, 작업 수, HTTP 응답을 확인할 수 있습니다.
Jodoo 앱은 공급업체명, 송장 번호, 송장 날짜, 송장 금액, PO 번호, 지급 기한, 예외 플래그를 저장해 검토와 후속 조치에 활용합니다.
데모 요약
이 구성은 시각적인 시나리오 캔버스, Run once 테스트, 모듈 이력을 원하는 운영팀에 적합합니다. 이 페이지에서는 시각적 시나리오 설정, 실제 실행, Jodoo Jodoo에 기록을 모두 확인할 수 있습니다. HTTP 모듈 증빙도 시각적으로 제공되어 메서드, 엔드포인트, 본문 유형, 파싱된 응답, 완료 상태를 코드 에디터 없이도 확인할 수 있습니다.
Make Custom webhook이 샘플 페이로드를 수신하고, HTTP 모듈이 구조화된 필드를 Jodoo로 전송합니다.
워크플로는 INV-2026-1048에 대해 예외 유형, 보류 사유, 지급 준비 상태, 배정된 검토자, 예산 담당자, 권장 해결 방안, 우선순위를 반환합니다.
Make 실행 이력에는 HTTP 모듈 완료, 작업 세부 정보, Jodoo 데이터 ID 응답이 표시됩니다.
Custom webhook으로 시작하고, 샘플 요청을 붙여넣은 뒤, 판단 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 설정합니다.
송장 예외 검토에서는 기본 Jodoo에 기록 이후 Make가 PO 불일치, 입고 확인 누락, 예산 담당자 승인 사례를 각각 별도 경로로 분기할 수 있습니다.
Jodoo는 송장 예외 레코드를 저장하고 다음 조치를 명확히 보여줍니다.
권장되는 다음 조치는 지급 보류, 입고 확인 요청, 그리고 예산 담당자에게 차이 승인 요청을 진행하는 것입니다.
결과물 키트에는 핸드북, Jodoo 필드 설계도, Make 워크플로 레시피가 포함됩니다.
플랫폼 설정 참고사항
Jodoo 레코드 모델은 일관되게 유지할 수 있지만, 각 에이전트 플랫폼은 구축 방식, 테스트 화면, 운영 배포 방식이 다릅니다.
이 검증본은 Run once를 사용하므로 유입 번들과 HTTP 응답을 확인할 수 있습니다.
HTTP 모듈은 메서드, URL, 본문 유형, 응답 파싱을 확인 가능하게 유지합니다.
시나리오 기록은 작업, 소요 시간, Jodoo에 기록 응답의 시각적 레코드를 제공합니다.
운영 배포 계획에는 webhook 소유권, 라우터, 오류 핸들러, 작업 사용량이 포함되어야 합니다.
공개 검증본은 Make의 Run once 모드를 사용하므로, 캡처된 스크린샷에서 시나리오 기록의 webhook 번들, 모듈 버블, 작업 수, HTTP 응답을 확인할 수 있습니다.
HTTP 모듈 증빙도 시각적으로 제공되어 메서드, 엔드포인트, 본문 유형, 파싱된 응답, 완료 상태를 코드 에디터 없이도 확인할 수 있습니다.
Custom webhook으로 시작하고, 샘플 요청을 붙여넣은 뒤, 판단 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 설정합니다.
고액 계약, 긴급 송장, 정보 누락 사례에 서로 다른 Jodoo 대기열이 필요하다면 기본 검증 후 라우터를 사용하세요.
Run once 검증본을 활성 워크플로로 전환하기 전에 작업 사용량, webhook 소유권, 시나리오 스케줄을 검토하세요.
실패한 Jodoo에 기록을 재시도하거나 수동 검토 경로로 이동할 수 있도록 HTTP 모듈 주변에 오류 핸들러를 추가하세요.
송장 예외 검토에서는 기본 Jodoo에 기록 이후 Make가 PO 불일치, 입고 확인 누락, 예산 담당자 승인 사례를 각각 별도 경로로 분기할 수 있습니다.
HTTP 모듈 본문에는 보류 사유, 지급 준비 상태, 예외 유형, 배정된 검토자를 명시적으로 매핑된 필드로 유지해야 합니다.
워크플로 키트
핸드북을 검토하고, 워크플로 레시피를 복사한 뒤, Make 워크플로를 적용할 때 Jodoo 필드 모델을 활용하세요.
Make가 시각적 시나리오를 처리하고, Jodoo가 담당자 대기열, 검토 상태, 후속 조치를 위한 송장 예외 검토 필드를 저장합니다.
재사용 가능한 워크플로
INV-2026-1048로 송장 예외 테스트를 시작합니다. Custom webhook으로 시작하고, 샘플 요청을 붙여넣은 뒤, 판단 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 설정합니다.
Make Custom webhook이 샘플 페이로드를 수신하고, HTTP 모듈이 구조화된 필드를 Jodoo로 전송합니다.
구조화된 JSON을 Jodoo Jodoo에 기록 브리지로 전송합니다. HTTP 모듈 증빙도 시각적으로 제공되어 메서드, 엔드포인트, 본문 유형, 파싱된 응답, 완료 상태를 코드 에디터 없이도 확인할 수 있습니다.
성공적인 플랫폼 실행과 Jodoo 데이터 ID를 보여줍니다. 공개 검증본은 Make의 Run once 모드를 사용하므로, 캡처된 스크린샷에서 시나리오 기록의 webhook 번들, 모듈 버블, 작업 수, HTTP 응답을 확인할 수 있습니다.
담당자 검토, 상태 추적, 후속 조치를 위한 필드를 저장합니다. Run once 검증본을 활성 워크플로로 전환하기 전에 작업 사용량, webhook 소유권, 시나리오 스케줄을 검토하세요.
워크플로 루프
Custom webhook이 먼저 합성 데이터로 송장 예외 검토를 수신하거나 시작합니다.
Make는 집중된 검토 지침을 적용해 예외 유형, 보류 사유, 지급 준비 상태, 배정된 검토자, 예산 담당자, 권장 해결 방안, 우선순위를 반환합니다.
HTTP 모듈이 구조화된 출력을 Jodoo Jodoo에 기록 브리지로 전송하고 데이터 ID를 받습니다.
송장 예외 검토에서는 기본 Jodoo에 기록 이후 Make가 PO 불일치, 입고 확인 누락, 예산 담당자 승인 사례를 각각 별도 경로로 분기할 수 있습니다.
HTTP 모듈 본문에는 보류 사유, 지급 준비 상태, 예외 유형, 배정된 검토자를 명시적으로 매핑된 필드로 유지해야 합니다.
시나리오 기록은 AP 팀에 유용합니다. 각 테스트 송장의 번들, 라우트, 작업 수, 응답 세부 정보가 하나의 시각적 실행 기록에 남기 때문입니다.
검증 이후 Make는 송장 배치를 위한 집계 모듈, 중복 송장 확인용 데이터 저장소, AP 예외 담당자를 위한 Slack 또는 이메일 모듈을 추가할 수 있습니다.
Custom webhook으로 시작하고, 샘플 요청을 붙여넣은 뒤, 판단 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 설정합니다.
고액 계약, 긴급 송장, 정보 누락 사례에 서로 다른 Jodoo 대기열이 필요하다면 기본 검증 후 라우터를 사용하세요.
Jodoo는 송장 승인 워크플로 레코드를 생성하고 공급업체명, 송장 번호, 송장 날짜, 송장 금액, PO 번호, 지급 기한, 예외 플래그, 예외 사유를 저장합니다.
팀은 대기열을 검토하고 담당자를 배정한 뒤, 다음 조치를 완료합니다: 지급 보류, 입고 확인 요청, 예산 담당자에게 차이 승인 요청.
Run once 검증본을 활성 워크플로로 전환하기 전에 작업 사용량, webhook 소유권, 시나리오 스케줄을 검토하세요.
실패한 Jodoo에 기록을 재시도하거나 수동 검토 경로로 이동할 수 있도록 HTTP 모듈 주변에 오류 핸들러를 추가하세요.
필드 매핑
| 에이전트 또는 소스 데이터 | Jodoo 레코드 필드 |
|---|---|
| 소스 요청 세부 정보 | 공급업체명, 송장 번호, 송장 날짜, 송장 금액 |
| 검토 판단 필드 | 예외 플래그, 예외 사유, 코딩 상태, 지급 준비 상태, 승인 상태 |
| 워크플로 응답 | 소스 플랫폼, 원본 워크플로 출력 |
에이전트 레시피
하나의 송장 예외 검토 요청을 검토하고 Jodoo가 저장, 라우팅, 보고할 수 있는 구조화된 필드를 반환합니다. Custom webhook으로 시작하고, 샘플 요청을 붙여넣은 뒤, 판단 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 설정합니다.
INV-2026-1048의 샘플 컨텍스트를 사용해 예외 유형, 보류 사유, 지급 준비 상태, 배정된 검토자, 예산 담당자, 권장 해결 방안, 우선순위를 결정하고, 권장되는 다음 조치를 구체적으로 유지합니다. 송장 예외 검토에서는 기본 Jodoo에 기록 이후 Make가 PO 불일치, 입고 확인 누락, 예산 담당자 승인 사례를 각각 별도 경로로 분기할 수 있습니다.
예측 가능한 JSON 객체를 HTTP 모듈을 통해 전송하세요. Jodoo는 실행할 때마다 동일한 필드명을 받아야 합니다. 운영팀이 캔버스, 필터, 라우터, 모듈 단위 실행 이력으로 업무 인계를 설명해야 할 때 Make가 유용합니다.
감사 컨텍스트를 위해 예외 유형, 보류 사유, 지급 준비 상태, 배정된 검토자, 예산 담당자, 권장 해결 방안, 우선순위, source_platform, agent_confidence, 원본 워크플로 출력을 반환합니다.
Run once 검증본을 활성 워크플로로 전환하기 전에 작업 사용량, webhook 소유권, 시나리오 스케줄을 검토하세요. 실패한 Jodoo에 기록을 재시도하거나 수동 검토 경로로 이동할 수 있도록 HTTP 모듈 주변에 오류 핸들러를 추가하세요. 운영 요청 데이터를 담는 모듈에 대해 webhook URL 소유자와 수정 권한자를 문서화하세요.
송장 예외 검토에서는 기본 Jodoo에 기록 이후 Make가 PO 불일치, 입고 확인 누락, 예산 담당자 승인 사례를 각각 별도 경로로 분기할 수 있습니다. HTTP 모듈 본문에는 보류 사유, 지급 준비 상태, 예외 유형, 배정된 검토자를 명시적으로 매핑된 필드로 유지해야 합니다. 시나리오 기록은 AP 팀에 유용합니다. 각 테스트 송장의 번들, 라우트, 작업 수, 응답 세부 정보가 하나의 시각적 실행 기록에 남기 때문입니다. 검증 이후 Make는 송장 배치를 위한 집계 모듈, 중복 송장 확인용 데이터 저장소, AP 예외 담당자를 위한 Slack 또는 이메일 모듈을 추가할 수 있습니다.
{
"invoice_number": "INV-2026-1048",
"vendor_name": "Atlas Packaging Co.",
"invoice_amount": 18640,
"po_number": "PO-7782",
"exception_type": "PO 금액 불일치",
"hold_reason": "금액 불일치 및 입고 확인 누락",
"payment_readiness": "보류 중",
"approval_status": "예외 검토",
"assigned_owner": "AP 예외 처리",
"budget_owner": "Maya Chen",
"recommended_resolution": "지급을 보류하고 차이 승인 요청",
"priority": "높음"
}Jodoo 스타터 앱
팀에 맞게 송장 예외 검토 워크플로를 적용할 때 이 필드 모델, 보기, 자동화를 활용하세요.
배포 체크리스트
워크플로
Make가 시각적 시나리오를 처리하고, Jodoo는 팀이 필터링, 배정, 검토할 수 있는 레코드를 유지합니다.
Custom webhook이 먼저 합성 데이터로 송장 예외 검토를 수신하거나 시작합니다.
Make는 집중된 검토 지침을 적용해 예외 유형, 보류 사유, 지급 준비 상태, 배정된 검토자, 예산 담당자, 권장 해결 방안, 우선순위를 반환합니다.
HTTP 모듈이 구조화된 출력을 Jodoo Jodoo에 기록 브리지로 전송하고 데이터 ID를 받습니다.
송장 예외 검토에서는 기본 Jodoo에 기록 이후 Make가 PO 불일치, 입고 확인 누락, 예산 담당자 승인 사례를 각각 별도 경로로 분기할 수 있습니다.
HTTP 모듈 본문에는 보류 사유, 지급 준비 상태, 예외 유형, 배정된 검토자를 명시적으로 매핑된 필드로 유지해야 합니다.
시나리오 기록은 AP 팀에 유용합니다. 각 테스트 송장의 번들, 라우트, 작업 수, 응답 세부 정보가 하나의 시각적 실행 기록에 남기 때문입니다.
검증 이후 Make는 송장 배치를 위한 집계 모듈, 중복 송장 확인용 데이터 저장소, AP 예외 담당자를 위한 Slack 또는 이메일 모듈을 추가할 수 있습니다.
Custom webhook으로 시작하고, 샘플 요청을 붙여넣은 뒤, 판단 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 설정합니다.
고액 계약, 긴급 송장, 정보 누락 사례에 서로 다른 Jodoo 대기열이 필요하다면 기본 검증 후 라우터를 사용하세요.
Jodoo는 송장 승인 워크플로 레코드를 생성하고 공급업체명, 송장 번호, 송장 날짜, 송장 금액, PO 번호, 지급 기한, 예외 플래그, 예외 사유를 저장합니다.
팀은 대기열을 검토하고 담당자를 배정한 뒤, 다음 조치를 완료합니다: 지급 보류, 입고 확인 요청, 예산 담당자에게 차이 승인 요청.
Run once 검증본을 활성 워크플로로 전환하기 전에 작업 사용량, webhook 소유권, 시나리오 스케줄을 검토하세요.
실패한 Jodoo에 기록을 재시도하거나 수동 검토 경로로 이동할 수 있도록 HTTP 모듈 주변에 오류 핸들러를 추가하세요.
Jodoo 레코드
워크플로 실행 후 Jodoo는 다음과 같은 지속형 송장 예외 필드를 유지합니다: 공급업체명, 송장 번호, 송장 날짜, 송장 금액, PO 번호, 지급 기한, 예외 플래그, 예외 사유.
실제 테스트 실행
스크린샷에는 합성 데이터와 함께 Make 설정, 성공적인 실행, 그리고 워크플로로 생성된 Jodoo 레코드가 표시됩니다.

Make Custom webhook이 샘플 페이로드를 수신하고, HTTP 모듈이 구조화된 필드를 Jodoo로 전송합니다.

Make 실행 이력에는 HTTP 모듈 완료, 작업 세부 정보, Jodoo 데이터 ID 응답이 표시됩니다.

송장 예외 검토가 Jodoo에 기록되었으며 공급업체명, 송장 번호, 송장 날짜, 송장 금액, PO 번호, 지급 기한 필드가 표시됩니다.
FAQ
Jodoo 레코드, 워크플로, 앱 템플릿과 에이전트 플랫폼을 함께 사용하는 방법에 대한 답변입니다.
네. 이 검증본은 합성 데이터, 실제 Make 실행, 그리고 검증 매니페스트가 포함된 확인된 Jodoo Jodoo에 기록 스크린샷을 사용했습니다.
시각적인 시나리오 캔버스, Run once 테스트, 모듈 이력이 필요한 운영팀이라면 Make가 적합합니다. 이후 Jodoo가 검토와 후속 조치를 위한 지속형 레코드를 유지합니다.
공개 검증본은 Make의 Run once 모드를 사용하므로, 캡처된 스크린샷에서 시나리오 기록의 webhook 번들, 모듈 버블, 작업 수, HTTP 응답을 확인할 수 있습니다. Custom webhook으로 시작하고, 샘플 요청을 붙여넣은 뒤, 판단 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 설정합니다. 송장 예외 검토에서는 기본 Jodoo에 기록 이후 Make가 PO 불일치, 입고 확인 누락, 예산 담당자 승인 사례를 각각 별도 경로로 분기할 수 있습니다.
Jodoo는 공급업체명, 송장 번호, 송장 날짜, 송장 금액, PO 번호, 지급 기한, 예외 플래그, 예외 사유, 코딩 상태, 지급 준비 상태와 함께 감사 컨텍스트를 위한 원본 워크플로 출력을 저장합니다.
네. 검증된 합성 실행으로 먼저 시작한 뒤, 송장 예외 검토 스키마가 안정화되면 양식, 포털, inbox, API 또는 내부 시스템을 연결할 수 있습니다. 고액 계약, 긴급 송장, 정보 누락 사례에 서로 다른 Jodoo 대기열이 필요하다면 기본 검증 후 라우터를 사용하세요.
워크플로가 판단 필드를 준비할 수는 있지만, 비즈니스 리스크, 지급 또는 법무 승인, 최종 운영 의사결정은 담당자가 계속 검토해야 합니다. 운영 요청 데이터를 담는 모듈에 대해 webhook URL 소유자와 수정 권한자를 문서화하세요.
다음 단계
검증된 Make 실행 1회부터 시작한 뒤, 동일한 Jodoo에 기록 패턴을 인접한 검토 대기열과 운영 업무 인계에도 재사용할 수 있습니다. Run once 검증본을 활성 워크플로로 전환하기 전에 작업 사용량, webhook 소유권, 시나리오 스케줄을 검토하세요.