ERP 매출채권을 위한 완전하고 명백히 합성된 고객 구현: 소스 온보딩, 표준 데이터, 현금 배부, 공제, 회수, 통제, KPI 벤치마킹, MCP 접근, 멀티 에이전트 예외 검토, 옵저버빌리티, UAT, 컷오버, 하이퍼케어.
이 저장소의 모든 SAP S/4HANA 스타일, Oracle Fusion 스타일, NetSuite 스타일 파일은 생성된 시뮬레이션입니다. 실제 내보내기나 실시간 통합이 아닙니다. KPI 변동은 합성 데이터에 대한 통제된 구현 벤치마크이며, 고객 영향이 아닙니다.
워크벤치는 깔끔한 분석 테이블이 아닌 고객 구성과 세 개의 비호환 소스 레이아웃에서 시작합니다. 검증 게이트를 적용하고, 결제 잔액을 보존하며, 예외를 라우팅하고, 회수 우선순위를 지정하고, 미달성 목표를 표시하며, 배포 팀이 발견부터 Go-Live까지 사용할 산출물을 생성합니다.
아키텍처는 의도적으로 금융 매칭을 결정론적이고 감사 가능하게 유지합니다. 에이전트는 판단이 많이 필요한 작업(예외 조사, 데이터 품질 진단, 회수 계획, Go-Live 모니터링)을 처리합니다. 에이전트는 ERP에 전기하거나, 환불을 발행하거나, 부채를 탕감하거나, 마스터 데이터를 변경할 수 없습니다.
flowchart LR
A["Three simulated ERP export sets"] --> B["Configuration-driven adapters"]
B --> C["Seven canonical receivables tables"]
C --> D["Validation control gate"]
D --> E["Deterministic cash matching"]
E --> F["Exception and collections queues"]
F --> G["MCP evidence tools"]
G --> H["Supervisor agent"]
H --> I["Cash Application Agent"]
H --> J["Data Quality Agent"]
H --> K["Collections Agent"]
I --> L["Human approval gate"]
J --> L
K --> L
E --> M["Controlled KPI benchmark"]
M --> N["Go Live Monitor Agent"]
O["OpenTelemetry traces"] -.-> B
O -.-> E
O -.-> H
O -.-> NRelated MCP server: finance-engines-mcp
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
o2c-workbench --project-root .
streamlit run app.py재현 가능한 seed-42 실행은 1,908개의 표준 레코드를 생성하고, 의도적인 중복 은행 거래 18건을 경고로 감지하며, 검증 오류를 0개 남깁니다. 정적 대시보드를 열거나 Streamlit 앱을 사용하세요.
서버는 현재 MCP Python SDK를 사용하며 구조화된 도구, 리소스, 프롬프트를 노출합니다. 로컬 클라이언트는 stdio를 사용해야 하며, 배포된 클라이언트는 Streamable HTTP를 사용할 수 있습니다.
o2c-mcp --transport stdio
o2c-mcp --transport streamable-http --port 8000도구: get_implementation_summary, investigate_payment, get_collection_priority, run_controlled_benchmark. 리소스: o2c://configuration, o2c://benchmark, o2c://observability.
기본 경로는 오프라인이며 결정론적이므로 검토자는 계정이나 API 키 없이 핸드오프와 통제를 재현할 수 있습니다. 이 경로는 output/agent_decisions.csv, output/agent_control_summary.json, OpenTelemetry 스팬을 생성합니다.
선택적 모델 기반 검토는 전문가 핸드오프와 구조화된 출력을 갖춘 OpenAI Agents SDK를 사용합니다:
pip install -e ".[ai]"
export OPENAI_API_KEY="..."
o2c-agent-review SAP-P001-09 --project-root .모델 경로는 벤치마크 KPI에 의도적으로 필요하지 않습니다. 권장할 수는 있지만 통제된 재무 작업을 실행할 수는 없습니다.
config/ — 구현 구성, 매핑, 허용 오차, 가중치, 라우팅, 통제, KPI 목표, 에이전트 한도.
data/raw/ — 생성된, 시각적으로 라벨이 표시된 시뮬레이션 ERP 내보내기.
data/canonical/ — 정규화된 고객, 송장, 결제, 송금, 공제, 약속, 활동.
src/o2c_workbench/ — 어댑터, 매칭, 회수, 통제, 에이전트, MCP, 옵저버빌리티, KPI 로직.
output/ — 벤치마크 증거, 대기열, 추적, 대시보드.
docs/ — 프로세스 설계, 매핑, 통제, RTM, 28개 UAT 케이스, 컷오버, 모니터링, 교육, 연구 기반.
deliverables/ — 구현 워크북.
demo/ — 5분 분량의 내레이션 구현 워크스루 및 대본.
KPI | 현재 상태 | 구성된 미래 상태 | 변동 |
자동 매칭률 | 10.0% | 80.7% | +70.7 pp |
수동 검토율 | 90.3% | 21.9% | -68.5 pp |
미배부 현금 | $2,192,667 | $550,209 | -$1,642,459 |
DSO | 115.9일 | 51.6일 | -64.3일 |
CEI | 8.7% | 75.7% | +67.0 pp |
연체 매출채권 | 69.5% | 44.9% | -24.6 pp |
처리 시간 | 67.7시간 | 13.0시간 | -54.7시간 |
네 가지 스트레치 목표는 여전히 미달이며, 따라서 모니터는 승리 자축이 아닌 조건부 Go를 권장합니다. 이는 의도적인 구현 현실성입니다. 미배부 현금과 잔여 초과 지불에 대한 인간 승인 통제 및 집중 하이퍼케어가 있을 때만 진행하십시오.
pytest -q결제 사례, MCP 전송 선택, 에이전트 핸드오프, 텔레메트리 규칙에 참고한 주요 출처는 연구 기반을 참조하세요.
Return the configured collection score evidence for one synthetic invoice.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it returns read-only evidence, so side effects are not impliedasi. No annotations are present, but as a getter, the behavior is somewhat inferable. It does not specify errors, auth, or configuration dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single precise sentence with no filler. It conveys the operation, target, and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple getter and the output schema exists, but it lacks usage guidance, alternatives, and explanation of what 'configured collection score evidence' actually contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though the parameter schema is only a raw string, the description ties the operation to 'one synthetic invoice', which effectively identifies the invoice_id parameter and explains its scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the operation ('Return'), the resource ('configured collection score evidence'), and the scope ('for one synthetic invoice'). This distinguishes it from the sibling tools, which target implementation summaries and payment investigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one synthetic invoice' gives a clear invocation context. However, it does not explicitly describe when to choose this tool over the sibling tools or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return controlled benchmark KPIs, data-quality status, disclaimers, and agent readiness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It states that the tool returns a summary, implying a read-only operation, and lists the types of content returned. However, it does not disclose prerequisites (e.g., whether a benchmark must already exist), data freshness, or any side effects, which leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the tool's purpose with no filler. Every phrase earns its place by naming a distinct output category.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters and an output schema exists, the description is largely complete. It lists the key output categories and indicates the tool's role as a summary provider. It could be slightly stronger by explicitly linking it to run_controlled_benchmark, but that is not essential for calling it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description correctly avoids inventing parameter semantics and instead focuses on what the output contains, which is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies a precise set of resources: controlled benchmark KPIs, data-quality status, disclaimers, and agent readiness. This clearly differentiates it from siblings like run_controlled_benchmark, which is the execution counterpart rather than the summary retrieval tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to call this tool versus its siblings. There is no explicit statement such as 'use after running a controlled benchmark' or 'use instead of investigate_payment'; the intended usage must be inferred from the name and resource list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return matching evidence and exception routing for one synthetic payment.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It says the tool returns evidence and exception routing, but it does not disclose whether this is a read-only operation, whether it requires special permissions, or what side effects (if any) exist. The presence of an output schema mitigates some ambiguity, but the description alone is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple one-parameter tool, though it could have added a brief usage note without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema, so the description does not need to explain return values. However, it lacks any context about when to use this tool, what 'exception routing' means, or how it relates to the sibling tools. For a tool with no annotations, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names the single parameter implicitly ('one synthetic payment' maps to payment_id) but does not explain the expected format, constraints, or how the parameter affects the result. With only one parameter, the gap is small, but the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('matching evidence and exception routing for one synthetic payment'), which clearly identifies the tool's function. It does not explicitly distinguish it from siblings, but the resource is specific enough that an agent can infer its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_implementation_summary or run_controlled_benchmark. The description implies it is for investigating a single synthetic payment, but it does not state exclusions or conditions that would route an agent to a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Regenerate synthetic source exports and controlled benchmark outputs; never connects to a genuine ERP.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: it never connects to a genuine ERP, which is valuable context beyond the schema. However, with no annotations provided, the description carries the full burden and doesn't disclose other behaviors like whether it overwrites existing outputs, how long it takes, or what the output schema contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, and the critical safety qualifier ('never connects to a genuine ERP') is included. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an output schema, the description is mostly adequate. However, it doesn't explain what 'controlled benchmark outputs' means in practice, what the output schema contains, or any side effects (e.g., overwriting files). The sibling tools suggest this is part of a larger workflow, but the description doesn't position it within that workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'seed' implicitly through 'regenerate' (deterministic regeneration), but doesn't explain the seed parameter's role or how it affects outputs. The single parameter is simple, so the gap is minor, but the description adds no explicit parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('regenerate') and resource ('synthetic source exports and controlled benchmark outputs'), and distinguishes itself from a genuine ERP connection. It is clear what the tool does, though it doesn't explicitly name sibling tools for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for synthetic/controlled benchmark scenarios and explicitly notes it never connects to a genuine ERP, which suggests when it should be used. However, it doesn't explicitly state when to use it versus alternatives like get_implementation_summary or investigate_payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_collection_priorityget_implementation_summaryinvestigate_paymentrun_controlled_benchmarkScored across 4 tools
Each tool targets a clearly distinct function: summary/KPIs, payment investigation, collection priority, and benchmark regeneration. There is no meaningful overlap or ambiguity between them.
All names use lowercase snake_case and follow a verb_object pattern, but the verb set is mixed (get, investigate, run). This is still predictable and readable, with only minor stylistic variance.
Four tools is a tight, well-scoped surface for a synthetic O2C benchmark workbench. Each tool serves a distinct purpose without unnecessary bloat or missing core functionality.
The tool set covers the main workflows: viewing benchmark status, investigating a payment, checking collection priority, and regenerating outputs. A minor gap is the lack of explicit discovery tools for available synthetic payment or invoice identifiers, but this may be addressed through the summary.
Governed retail, FMCG, and CPG operational tools: runs, cases, approvals, audit-ready execution.
Tesorio's order-to-cash tools — query customers, invoices, receivables, payments, and more.
Quote-to-cash tools: parse invoices and POs, match POs to invoices, collection emails, billing math.
Paid deterministic data-quality and execution-verification tools for AI agents.
