@raishin/vanguard-frontier-agentic 2.11.0 → 2.13.1

package/skills/sap/sap-mdg-master-data-quality-review/references/official-sources.md

@@ -0,0 +1,89 @@
+# Official sources — SAP MDG Master Data Quality Review
+
+Use this reference when grounding MDG data model assessment, validation and derivation rule review, governance workflow analysis, consolidation and mass processing evaluation, data quality KPI framework review, and key mapping configuration assessment.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP Master Data Governance documentation). No live-system evidence is collected by this skill.
+
+## MDG data model and entity types
+
+- SAP Master Data Governance — Data Modeling
+  https://help.sap.com/docs/SAP_MASTER_DATA_GOVERNANCE/master-data-governance/data-modeling
+  source_owner: SAP SE
+  topic_supported: MDG data model framework, entity type definition, node structure (single-object, multi-object, reuse object), key field configuration, data model extensibility using EEWB/AXT
+  why_needed: Primary reference for evaluating MDG data model design completeness, extensibility approach soundness, and alignment with the standard MDG node and entity type model
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Validation and derivation rules (BRFplus)
+
+- MDG Validation and Derivation Rules
+  https://help.sap.com/docs/SAP_MASTER_DATA_GOVERNANCE/master-data-governance/validation-and-derivation-rules
+  source_owner: SAP SE
+  topic_supported: BRFplus-based validation rule configuration for MDG, derivation rule design, mandatory field check rules, cross-field referential integrity rules, derivation sequence and dependency order, BAdI-based custom validation hooks
+  why_needed: Authoritative reference for assessing validation rule coverage and derivation design — required to classify validation gap findings and silent derivation overwrite risks
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Governance workflow
+
+- MDG Governance Workflow
+  https://help.sap.com/docs/SAP_MASTER_DATA_GOVERNANCE/master-data-governance/governance-workflow
+  source_owner: SAP SE
+  topic_supported: Change request type definition, MDG workflow template design (SAP Business Workflow or Flexible Workflow), step ownership and agent determination, parallel vs. sequential approval step configuration, deadline and escalation configuration, workflow routing via custom BAdI
+  why_needed: Defines the MDG workflow governance model — required to assess workflow step ownership gaps, missing escalation paths, and change request routing correctness
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Duplicate check and matching
+
+- MDG Duplicate Check
+  https://help.sap.com/docs/SAP_MASTER_DATA_GOVERNANCE/master-data-governance/duplicate-check
+  source_owner: SAP SE
+  topic_supported: Duplicate check configuration for MDG, match profile setup, matching algorithm selection (fuzzy vs. exact), threshold configuration, duplicate candidate display and resolution workflow
+  why_needed: Primary reference for duplicate detection review — required to classify matching threshold misconfiguration and false positive or false negative duplicate check findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Consolidation and mass processing
+
+- MDG Consolidation
+  https://help.sap.com/docs/SAP_MASTER_DATA_GOVERNANCE/master-data-governance/consolidation
+  source_owner: SAP SE
+  topic_supported: MDG consolidation data model, source system record import, matching and best record calculation, consolidation workflow, mass processing configuration, error handling for consolidation failures
+  why_needed: Defines the MDG consolidation and mass processing model — required to assess best record calculation logic, matching rule quality, and mass change authorization control gaps
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Data quality KPI framework
+
+- MDG Data Quality — Key Performance Indicators
+  https://help.sap.com/docs/SAP_MASTER_DATA_GOVERNANCE/master-data-governance/data-quality-management
+  source_owner: SAP SE
+  topic_supported: MDG data quality KPI definition, rule-to-KPI mapping, data quality dimension coverage (completeness, conformance, uniqueness, timeliness), KPI threshold configuration, MDG data quality cockpit and dashboard
+  why_needed: Primary reference for evaluating KPI framework completeness and metric coverage — required to identify KPI blind spots and threshold misconfiguration findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Key mapping and replication
+
+- MDG Key Mapping
+  https://help.sap.com/docs/SAP_MASTER_DATA_GOVERNANCE/master-data-governance/key-mapping
+  source_owner: SAP SE
+  topic_supported: Key mapping object type configuration, source system–to–MDG key mapping completeness, MDG replication framework (SOA/Web Services replication model), ALE/IDoc replication alternative, target system key mapping and distribution model
+  why_needed: Defines the MDG key mapping and replication model — required to assess key mapping gaps, replication model design, and replication error monitoring coverage
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## MDG for Finance (G/L accounts, cost centers)
+
+- MDG for Finance
+  https://help.sap.com/docs/SAP_MASTER_DATA_GOVERNANCE/master-data-governance/mdg-for-finance
+  source_owner: SAP SE
+  topic_supported: MDG Finance domain scope (G/L account, cost center, profit center, cost element, internal order), MDG for Finance data model, integration with SAP S/4HANA Finance master data
+  why_needed: Domain-specific reference for MDG Finance governance review — required when the in-scope MDG domains include financial master data managed in the MDG Finance edition
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal and MDG documentation describe the designed governance model, data model framework, validation rule configuration approach, workflow design options, and data quality KPI framework. They do not prove what BRFplus rules are active in the user's MDG system, what change request types are configured, what KPIs are measured, or whether key mapping is complete. Users must supply BRFplus rule summaries, workflow configuration descriptions, data model documents, KPI dashboard exports, or written descriptions of their MDG landscape for concrete assessment.

package/skills/sap/sap-mdg-master-data-quality-review/references/safety-checklist.md

@@ -0,0 +1,37 @@
+# Safety checklist — SAP MDG Master Data Quality Review
+
+Use before making any MDG configuration or data governance remediation recommendation, especially for findings involving governance workflow, validation rules, mass processing, or key mapping.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP MDG system, S/4HANA backend, Fiori launchpad, BRFplus runtime, or replication target system. This skill reviews artifacts only.
+- Do not accept or request SAP logon credentials, MDG admin access, RFC connection details, or direct database access.
+- Do not create, modify, approve, reject, activate, or delete any master data change request, consolidation object, mass change template run, or governance workflow step. This skill is strictly advisory.
+- Do not execute or trigger MDG mass change templates, consolidation runs, or replication jobs. These operations can affect large volumes of master data records and must be executed by authorized MDG administrators in a controlled change window.
+- Do not recommend activating BRFplus validation or derivation rules directly in a production MDG system. All rule changes must first be tested in a development or quality system with representative change request data.
+- Do not use memory alone to determine which BRFplus application or decision table governs a specific MDG validation scenario. BRFplus rule assessment must be grounded in user-provided rule exports or official MDG documentation.
+- Do not conflate MDG staging area data with active master data. Changes in the MDG staging area are not effective until a change request is approved and activated. Governance gaps in the workflow layer can prevent activation — but data in the staging area is not yet live.
+
+## What people get wrong
+
+- **Treating all derivation rules as safe**: Derivation rules that silently overwrite fields the user has already populated are a data quality risk, not just a convenience feature. Organizations often add derivations to improve consistency but do not account for cases where the derivation logic is wrong for edge cases — and the user cannot tell that their input was overwritten.
+- **Assuming BRFplus covers all validation**: BRFplus is the primary validation tool in MDG, but custom BAdI implementations (USMD_RULE_SERVICE or equivalent) can override or bypass BRFplus rules. Both layers must be reviewed for a complete validation coverage picture.
+- **Overlooking the bypass risk in direct activation**: Some MDG change request type configurations allow a "direct activation" path for certain user groups or attribute conditions, bypassing the normal workflow approval chain. This is a common governance gap that is not always visible in the standard workflow template view — it requires checking the change request type customizing directly.
+- **Confusing MDG consolidation with data migration**: MDG consolidation is an ongoing governance process for deduplicating and harmonizing master data from multiple source systems. It is not a one-time migration activity. Consolidation run errors that accumulate in a production system without monitoring are an ongoing data quality risk.
+- **Treating data quality KPIs as a reporting-only concern**: MDG data quality KPIs are most valuable when they drive workflow — for example, triggering a data steward review task when a score falls below threshold. KPIs that are calculated but never acted on provide measurement without governance.
+- **Missing replication monitoring as a governance gap**: When MDG replication to a target system fails silently, the target system continues to operate with stale or incorrect master data. Missing replication error monitoring is a governance gap because the organization cannot tell which records are out of sync.
+- **Conflating MDG for Finance with MDG for Business Partner**: These are distinct MDG domains with separate data models, governance workflows, and validation frameworks. A well-governed MDG for Business Partner domain does not imply that MDG for Finance G/L account and cost center governance is equally mature — each domain must be assessed independently.
+
+## When to push back
+
+- Push back when a governance bypass risk (direct activation without workflow, unrestricted mass change execution) is identified — escalate to the data governance team before recommending any other remediation.
+- Push back when the user asks to confirm MDG governance compliance from memory alone without providing BRFplus rule exports, workflow configuration descriptions, or data model documents.
+- Push back when the request requires live MDG system access (active change request status, live data quality scores, replication queue state) — state clearly that live inspection is out of scope and ask the user to supply the relevant export or description.
+- Push back when asked to create, modify, approve, activate, or run any master data operation — this is an absolute boundary and must be refused in all circumstances.
+- Push back when the user asks to assess duplicate detection quality without providing the match profile configuration or a sample of known duplicate pairs — threshold assessment without data cannot be meaningful.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Master Data Governance Help Portal documentation, BRFplus documentation, MDG data model guides, or SAP MDG best practice guidance
+- `user-provided evidence` — BRFplus rule exports, workflow configuration summaries, KPI dashboard descriptions, key mapping configuration notes, data model design documents, consolidation run logs, or written descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled as such

package/skills/sap/sap-mdg-master-data-quality-review/references/workflow-and-output.md

@@ -0,0 +1,91 @@
+# Workflow and output contract — SAP MDG Master Data Quality Review
+
+Use this reference for all MDG finding classification, risk level assignment, remediation path selection, and output formatting.
+
+## MDG finding taxonomy
+
+| Domain | Finding class | Description |
+|--------|--------------|-------------|
+| `data-model` | `non-standard-node-structure` | Custom entity type uses a node structure that deviates from the MDG standard single-object or multi-object model without a documented justification — creates maintenance and upgrade risk |
+| `data-model` | `missing-key-field-constraint` | Entity type key field has no uniqueness constraint or reuse object linkage — allows duplicate key values to be created in the MDG staging area |
+| `data-model` | `extensibility-approach-risk` | Data model extended via unsupported enhancement approach (direct table modification) rather than EEWB/AXT — creates upgrade incompatibility |
+| `validations` | `mandatory-field-check-missing` | BRFplus validation rule does not enforce a field that the business data standard requires as mandatory — incomplete governance leaves required data absent |
+| `validations` | `referential-integrity-gap` | Cross-field referential check (e.g., cost center valid for company code, profit center assigned to controlling area) is absent or inactive |
+| `validations` | `duplicate-threshold-too-loose` | Matching algorithm threshold is set so low that known duplicate patterns are not flagged — duplicates enter the active data without governance review |
+| `validations` | `duplicate-threshold-too-strict` | Matching algorithm threshold produces excessive false positives — consolidation workflow is bottlenecked by non-duplicate candidates requiring manual resolution |
+| `derivations` | `silent-overwrite-no-notification` | Derivation rule overwrites a user-entered field without notifying the change request initiator — user cannot detect when the system replaces their input |
+| `derivations` | `derivation-dependency-wrong-order` | Derivation rules execute in an order where a later rule depends on a field populated by an earlier rule, but that dependency is not enforced — derivation produces incorrect values on the first pass |
+| `derivations` | `derivation-coverage-gap` | A field that should be auto-derived (e.g., tax jurisdiction from postal code, purchasing organization from plant) has no derivation rule — users must manually populate it, creating inconsistency |
+| `workflow` | `step-no-owner` | Workflow step has no assigned agent (user, role, or organizational unit) — change request can stall indefinitely at this step |
+| `workflow` | `missing-escalation` | Workflow template has no deadline enforcement or escalation routing for overdue steps — process bottlenecks have no governance response |
+| `workflow` | `routing-logic-gap` | Workflow routing logic does not cover all valid attribute combinations for the change request type — some change requests fall to an incorrect or no approver |
+| `workflow` | `bypass-path-via-direct-activation` | Change request type allows direct activation without workflow approval for certain conditions — bypasses the governance review layer |
+| `consolidation` | `best-record-logic-undocumented` | Best record calculation logic is not documented — reviewers cannot determine which source system fields take precedence when multiple records conflict |
+| `consolidation` | `mass-change-unrestricted-access` | MDG mass change template execution is not restricted by authorization object or role — any user with basic MDG access can run bulk master data changes |
+| `consolidation` | `consolidation-error-not-monitored` | Consolidation run errors are not routed to a monitored queue or alert — failed consolidations may go undetected |
+| `data-quality-kpis` | `domain-not-covered` | An in-scope MDG domain (e.g., business partner, supplier, material) has no data quality KPI defined — governance blind spot for that domain |
+| `data-quality-kpis` | `dimension-gap` | KPI framework measures completeness but not conformance, uniqueness, or timeliness for one or more in-scope domains — partial quality view |
+| `data-quality-kpis` | `threshold-not-set` | Data quality KPI has no threshold configured — score is calculated but no alert or workflow is triggered when quality falls below acceptable levels |
+| `key-mapping` | `source-system-mapping-gap` | Source system is not mapped in the MDG key mapping object for one or more entity types — replication from that system cannot be routed correctly |
+| `key-mapping` | `replication-error-not-monitored` | MDG replication errors (SOA fault messages, ALE/IDoc errors) are not monitored — replication failures silently accumulate in the error queue |
+
+## Risk level assignment
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Governance bypass via direct activation without workflow; unrestricted mass change template execution enabling bulk unauthorized master data modification; undetected duplicate propagation into transactional systems |
+| `high` | Derivation silent overwrite without notification; missing mandatory field validation for a regulatory or financially material field; key mapping gap causing replication failures to a critical target system; missing escalation path causing indefinite workflow stall |
+| `medium` | Workflow step with no owner; duplicate threshold misconfiguration (too loose or too strict); KPI domain not covered; consolidation error not monitored; derivation dependency order issue |
+| `low` | Best practice deviation in data model design; non-standard extensibility approach with low immediate risk; cosmetic KPI threshold gap in a low-risk domain |
+
+## Remediation path decision tree
+
+For each finding:
+
+1. **Is this a governance bypass (direct activation without workflow, or unrestricted mass change execution)?**
+   - Yes → `critical`. Immediately escalate to the data governance team. Disable direct activation for the affected change request type or restrict mass change template execution by role. Do not approve until the bypass path is closed and tested in a non-production system.
+   - No → continue.
+
+2. **Is this a derivation that silently overwrites a user-entered field without notification?**
+   - Yes → `high`. Add a notification step to the derivation that informs the change request initiator when their input is overridden by the derivation. Review whether the derivation logic is correct and whether a notification is sufficient or whether the overwrite should be blocked pending user confirmation.
+   - No → continue.
+
+3. **Is this a mandatory field validation gap for a regulatory or financially material field?**
+   - Yes → `high`. Add a BRFplus validation rule for the missing mandatory field. Test the rule in a development system against representative change requests before activating in production. Coordinate with the data steward team to define the enforcement scope.
+   - No → continue.
+
+4. **Is this a key mapping gap causing replication failures to a critical target system?**
+   - Yes → `high`. Complete the key mapping for the affected entity type and source system. Configure replication error monitoring to alert the MDG operations team. Reconcile any master data records in the target system that were not replicated during the gap period.
+   - No → continue.
+
+5. **Is this a workflow step with no owner or no escalation path?**
+   - Yes → `medium`. Assign an agent (user, role, or organizational unit) to the unowned step. Configure a deadline and escalation routing (to manager or data governance team) for overdue steps. Review the workflow agent determination BAdI if routing is logic-driven.
+   - No → continue.
+
+6. **Is this a data quality KPI gap (domain not covered, dimension missing, threshold not set)?**
+   - Yes → `medium`. Extend the KPI framework to cover the missing domain or dimension. Set enforcement thresholds for each KPI. Configure a scheduled data quality run and dashboard alert for scores below threshold.
+   - No → classify as `low` and provide best practice guidance.
+
+## Workflow
+
+1. **Receive artifacts** — BRFplus rule exports or summaries, workflow configuration descriptions, data model design documents, KPI dashboard exports, key mapping configuration notes, consolidation design summaries, or written descriptions of the MDG landscape.
+2. **Classify each finding** by MDG governance domain and finding class.
+3. **Assign risk level** per the table above (critical / high / medium / low).
+4. **Flag governance bypass risks** (direct activation, unrestricted mass change) immediately — escalate before other remediation.
+5. **Apply remediation decision tree** per finding.
+6. **Prioritize** — governance bypass and mass change risks first; then high derivation, validation, key mapping, and escalation gap findings; then medium workflow and KPI gap findings; then low best-practice items.
+7. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. MDG governance domain and finding class per finding
+2. Evidence label (documentation-based / user-provided evidence / inference)
+3. Risk level per finding (critical / high / medium / low)
+4. Finding detail: affected MDG domain, change request type, entity type, BRFplus rule ID (if provided), workflow step, KPI name, or key mapping object
+5. Recommended remediation action (BRFplus rule addition, derivation notification step, workflow agent assignment, escalation configuration, matching threshold adjustment, KPI extension, key mapping completion, mass change authorization tightening, etc.)
+6. MDG governance posture after remediation
+7. Escalation notice for any governance bypass risk — explicit statement that this requires data governance team sign-off before proceeding
+8. Prioritized remediation sequence
+9. Confirmation that no live MDG system was accessed and no master data records were created, modified, approved, or activated in this review

package/skills/sap/sap-order-to-cash-review/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: sap-order-to-cash-review
+description: Review SAP S/4HANA Order-to-Cash (OTC) processes: order management configuration, pricing procedure design, credit management controls, billing and revenue recognition, order and delivery blocks and holds, fulfillment exception management, Days Sales Outstanding (DSO) drivers, and cash application. Flags control gaps, revenue leakage patterns, pricing errors, unresolved order blocks, credit management weaknesses, and DSO drivers. Does not create sales orders, release order blocks, post billing documents, or mutate any live OTC system.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: finance
+  lifecycle: experimental
+---
+
+# SAP Order-to-Cash Review
+
+## Purpose
+
+Assess the process design quality, configuration posture, and control coverage of SAP S/4HANA Order-to-Cash (OTC) processes. Evaluate order management configuration by reviewing sales order document type design, partner function and organizational assignment, order entry completeness controls, and whether order incompletion procedures are configured to prevent downstream fulfillment failures. Assess pricing procedure design by reviewing condition type configuration, pricing procedure determination, pricing control parameters (mandatory condition types, statistical conditions, calculation types), and whether pricing errors or gaps can result in orders processed at incorrect prices. Evaluate credit management controls by reviewing credit control area configuration, credit limit assignment governance, automatic credit check configuration (static vs. dynamic), blocked order management, and whether the credit management process allows unauthorized credit limit overrides. Assess billing and revenue recognition by reviewing billing document type configuration, billing plan design for milestone or periodic billing, SD–FI integration for revenue posting, and whether billing schedule adherence is monitored. Review order and delivery blocks and holds by examining standard block reasons (credit block, incompletion block, listing block, delivery block), block release authorization governance, aged block management, and whether unresolved blocks represent revenue and customer experience risk. Evaluate fulfillment exception management by reviewing availability check configuration, transfer of requirements (TOR) design, delivery split logic, goods issue (GI) posting governance, and whether fulfillment exceptions are tracked and resolved within target cycle times. Assess Days Sales Outstanding (DSO) drivers by reviewing billing cycle timing, cash application process design, dispute management configuration in SAP Dispute Management (FSCM), dunning procedure governance, and deductions management. Does not connect to or mutate any live SAP S/4HANA Sales (SD) system or Finance (FI) system. Never creates, modifies, or releases sales orders, delivery documents, billing documents, or customer payments.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review SAP S/4HANA SD sales order management configuration: sales order document type design, partner function determination, organizational assignment (sales area, plant, shipping point), order incompletion procedure configuration, order entry validation, and pricing determination completeness controls,
+- assess SAP S/4HANA pricing procedure design: pricing procedure assignment (VKOA and condition type determination), mandatory condition type configuration, pricing control parameters (ERL and ERB account determination), manual price override authorization controls, pricing error detection, free goods and discount condition type governance, and whether pricing gaps allow orders to be processed at zero or incorrect prices,
+- evaluate SAP S/4HANA credit management configuration: credit control area assignment, credit limit governance (who can set, modify, or override credit limits), automatic credit check type (static check, dynamic check, maximum document value), credit block reason design, credit block release authorization, and whether the credit management process provides adequate controls over the credit risk exposure in the order book,
+- review billing and revenue recognition process design: billing document type configuration (F1, F2, credit memo, debit memo), billing plan types (milestone billing, periodic billing, down payment), SD–FI account determination for revenue and deferred revenue posting, billing schedule completion rate monitoring, and whether billing cycle timing aligns with contract terms and IFRS 15 or ASC 606 revenue recognition requirements,
+- assess order and delivery block management: standard block reason configuration (credit block A, listing and exclusion block B, incompletion block C, delivery block), block aging patterns and whether aged blocks represent systemic fulfillment or commercial policy issues, block release authorization segregation, and whether unresolved blocks in the order book represent revenue at risk,
+- evaluate fulfillment exception management: availability check configuration (ATP checking rule, checking scope, replenishment lead time), transfer of requirements (TOR) design and accuracy, delivery split logic and split criteria, partial delivery tolerance configuration, goods issue (GI) posting timing controls, and whether fulfillment exception resolution cycle time meets customer service level requirements,
+- assess Days Sales Outstanding (DSO) drivers: billing cycle timing relative to delivery completion, cash application process design and remittance matching efficiency, SAP Dispute Management (FSCM) configuration for invoice dispute tracking and resolution, dunning procedure configuration (dunning levels, dunning amounts, dunning escalation), deductions management process design, and whether the collections process is supported by adequate receivables analytics,
+- review revenue leakage patterns in the OTC process: unauthorized pricing overrides, unbilled deliveries (delivered goods not yet invoiced), billing plan milestone slippage, unapplied cash sitting in the clearing account, unresolved credit memos that should have been applied against outstanding receivables, and whether revenue completeness controls are in place across the OTC cycle.
+
+## When not to use
+
+- When the user needs live inspection of SAP S/4HANA sales orders, deliveries, billing documents, or customer accounts — this skill accepts only user-provided configuration summaries, block aging reports, billing schedule adherence reports, DSO analytics, dispute management summaries, or written descriptions of the OTC landscape.
+- When the request is about SAP S/4HANA Finance Accounts Receivable (FI-AR) period-end close controls or G/L posting controls without an OTC revenue or DSO angle — use `sap-finance-fico-controls-review` for FI-AR financial control assessment.
+- When the request concerns SAP CRM or SAP Sales Cloud (formerly C/4HANA Sales) customer relationship management processes rather than SAP S/4HANA SD order fulfillment and billing — those are distinct front-office platforms.
+- When the request is about SAP Revenue Accounting and Reporting (RAR) for multi-element arrangement accounting under IFRS 15 or ASC 606 without an S/4HANA SD billing configuration angle — SAP RAR is a distinct module with its own configuration scope.
+- When the request concerns SAP Transportation Management (TM) route planning or freight settlement rather than OTC fulfillment exception management at the delivery level.
+
+## Does not touch live systems
+
+This skill operates on user-provided configuration descriptions, order block aging reports, billing schedule adherence reports, pricing procedure documentation, credit management configuration summaries, DSO analytics, dispute management reports, dunning procedure documentation, or written descriptions of the OTC landscape. It does not connect to any SAP S/4HANA Sales (SD) system, SAP S/4HANA Finance (FI) system, Fiori launchpad, SAP GUI session, or backend RFC. It does not create, modify, release, or cancel sales orders, delivery documents, billing documents, customer credit limits, or customer payments. All live inspection is out of scope.
+
+**This skill never creates or releases OTC documents.** No sales order creation, no delivery release, no goods issue posting, no billing document creation, no credit limit modification, and no customer payment posting is performed or recommended as a direct action in this skill's execution path. All remediation recommendations describe configuration and process design changes to be implemented and tested in a non-production environment.
+
+## Lean operating rules
+
+- Classify OTC control findings before recommending. Every finding must be assigned to an OTC process domain (order management / pricing / credit management / billing and revenue / order blocks / fulfillment exceptions / DSO drivers / revenue completeness) before a remediation path is proposed.
+- Pricing overrides without authorization control are a first-order revenue leakage risk. Any configuration allowing users to override pricing condition types to zero or below standard without an approval workflow is a `high` revenue integrity finding — it enables unauthorized discounting that may not be visible in standard OTC reporting.
+- Unbilled deliveries are a direct revenue completeness risk. Any goods issue posted but not yet invoiced beyond the standard billing cycle window represents a revenue recognition delay or leakage risk. Monitor and age unbilled deliveries as a revenue completeness control.
+- Credit blocks released without documented authorization expose the business to credit risk. A credit block release process that allows the releasing user to also be the salesperson who entered the order — without a separate credit management approver — is an SoD gap in the credit risk control model.
+- Aged order blocks (beyond the standard resolution target) indicate systemic process failures. Order blocks that age without resolution represent both revenue risk (delayed fulfillment) and customer experience risk. A pattern of aged blocks in a specific block reason category signals a root cause requiring process or configuration correction, not a block-by-block resolution approach.
+- DSO above industry benchmark for the business model requires a multi-driver analysis. DSO elevation can stem from billing cycle timing, dispute volume and resolution cycle time, deductions backlog, cash application delays, or dunning process gaps. Attributing DSO solely to customer behavior without a process driver analysis is an incomplete finding.
+- Evidence from user-provided artifacts or official SAP S/4HANA Sales and Finance documentation takes precedence over inference.
+- Load only the reference needed for the OTC domain under review.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP S/4HANA Sales and Distribution, SAP S/4HANA Finance Accounts Receivable, SAP FSCM Dispute Management, or SAP Help Portal OTC documentation, or SAP billing and revenue recognition guidance
+- `user-provided evidence` — order block aging reports, billing schedule adherence reports, pricing procedure documentation, credit management configuration summaries, DSO analytics, dispute management reports, dunning procedure documentation, unbilled delivery reports, or written descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no SAP S/4HANA RFC call, Fiori OData API invocation, SAP GUI session, BAPI execution, or direct database query in this skill's execution path. Users must supply configuration descriptions, order block aging reports, billing schedule adherence data, credit management summaries, DSO analytics, dispute management reports, or written descriptions of their OTC landscape for this skill to review.
+
+**This skill never creates or releases OTC documents.** Recommendations describing remediation always apply to configuration, authorization, or process design — not to direct sales order creation, delivery release, billing document generation, credit limit change, or customer payment posting.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — OTC finding taxonomy, severity assignment, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common OTC review mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP S/4HANA Sales and Distribution, credit management, billing, FSCM Dispute Management, and OTC documentation.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: OTC process domain(s) affected (order management / pricing / credit management / billing and revenue / order blocks / fulfillment exceptions / DSO drivers / revenue completeness) and specific finding(s) per domain.
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: critical (unauthorized pricing at zero enabling fraudulent revenue leakage; credit block release without any credit management authorization; unbilled delivery backlog above a material revenue threshold) / high (pricing override without approval workflow; SoD gap in credit block release; billing plan milestone slippage creating revenue recognition risk; DSO elevation driven by unaddressed billing or dispute process gaps; aged order block backlog representing material revenue at risk) / medium (availability check gap causing fulfillment splits not aligned with customer requirements; dunning procedure without adequate escalation levels; incompletion procedure not covering required fields; cash application remittance matching inefficiency) / low (best practice deviation in billing document type design or partner function configuration).
+- **Recommended action**: specific configuration or process remediation per finding (pricing override approval workflow, credit block SoD separation, billing schedule monitoring setup, unbilled delivery aging control, order incompletion procedure extension, availability check rule alignment, dunning level addition, dispute management configuration, cash application matching rule improvement, etc.).
+- **Refusal / escalation triggers**: if unauthorized pricing at zero or revenue fraud indicators are found, escalate to the audit and finance team before any further OTC transactions are processed. If a finding requires live SAP S/4HANA system inspection, state that clearly and ask the user to supply the relevant export or description.
+- **Business impact**: revenue leakage or deferral risk, credit loss exposure, customer service level impact from aged blocks or fulfillment exceptions, working capital impact from DSO elevation, audit finding risk for revenue completeness controls, IFRS 15 or ASC 606 compliance risk from billing plan slippage.
+- **Next verification step**: confirm recommended configuration changes against the user's current SAP S/4HANA SD and FI setup in a non-production system before promoting to production.

package/skills/sap/sap-order-to-cash-review/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Order-to-Cash Review"
+  short_description: "Review SAP S/4HANA Order-to-Cash (OTC) processes: order management, pricing procedure design, credit management controls, billing and revenue recognition, order and delivery blocks, fulfillment exception management, DSO drivers, and cash application. Does not create sales orders, release blocks, post billing documents, or access live OTC systems."
+  default_prompt: "Use $sap-order-to-cash-review to assess the provided SAP S/4HANA Order-to-Cash configuration and process data. Classify each finding by OTC process domain (order management, pricing, credit management, billing and revenue, order blocks, fulfillment exceptions, DSO drivers, revenue completeness), assign a risk level (critical/high/medium/low), and recommend specific remediation actions. Flag any unauthorized pricing at zero or revenue fraud indicators for immediate escalation. State evidence level (documentation-based, user-provided, inference) and confirm that no live system access, sales order creation, order block release, billing document posting, or customer payment modification is performed."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-sales/sales-order-processing"
+      description: "SAP S/4HANA Sales and Distribution documentation — primary reference for order management and OTC process review"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-order-to-cash-review/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "sap-order-to-cash-review",
+  "name": "SAP Order-to-Cash Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review SAP S/4HANA Order-to-Cash (OTC) processes: order management, pricing procedure design, credit management controls, billing and revenue recognition, order and delivery blocks, fulfillment exception management, DSO drivers, and cash application. Does not create sales orders, release order blocks, post billing documents, or access live OTC systems.",
+  "source_type": "original",
+  "category": "finance",
+  "official_docs": [
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-sales/sales-order-processing",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-sales/pricing-and-conditions",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-sales/credit-management",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-sales/billing",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-sales/availability-check-and-transfer-of-requirements",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/dispute-management",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/revenue-accounting-and-reporting"
+  ],
+  "security_notes": "Does not access live SAP S/4HANA Sales (SD) systems, SAP S/4HANA Finance (FI) systems, Fiori launchpads, SAP GUI sessions, or any production OTC database. Accepts only user-provided configuration descriptions, order block aging reports, billing schedule adherence reports, pricing procedure documentation, credit management summaries, DSO analytics, dispute management reports, dunning procedure documentation, or written descriptions of the OTC landscape. Never request or accept SAP logon credentials, RFC connection details, or direct database access. Never creates, modifies, releases, or cancels sales orders, delivery documents, billing documents, customer credit limits, or customer payments. Revenue fraud indicators (unauthorized pricing at zero, material unbilled delivery backlog) must be escalated to the audit and finance team — this skill does not approve transactions or close audit findings.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-order-to-cash-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-order-to-cash-review/references/official-sources.md

@@ -0,0 +1,79 @@
+# Official sources — SAP Order-to-Cash Review
+
+Use this reference when grounding order management configuration assessment, pricing procedure design review, credit management control evaluation, billing and revenue recognition analysis, order block management review, fulfillment exception assessment, DSO driver analysis, and revenue completeness control evaluation.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP S/4HANA Sales and Distribution documentation, SAP S/4HANA Finance documentation). No live-system evidence is collected by this skill.
+
+## SAP S/4HANA Sales — Order Management and Document Type Configuration
+
+- SAP S/4HANA Sales — Sales Order Processing
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-sales/sales-order-processing
+  source_owner: SAP SE
+  topic_supported: Sales order document type configuration, partner function determination, organizational assignment (sales area, distribution channel, division, plant, shipping point), order incompletion procedure configuration (incompletion log), order entry validation controls
+  why_needed: Primary reference for assessing order management configuration quality — defines the SAP SD sales order processing model, document type assignment, and incompletion procedure framework used to classify order management findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP S/4HANA Sales — Pricing Procedure Configuration
+
+- SAP S/4HANA Sales — Pricing and Conditions
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-sales/pricing-and-conditions
+  source_owner: SAP SE
+  topic_supported: Pricing procedure design and assignment (VKOA, condition type determination), mandatory condition type configuration, pricing control parameters (calculation type, condition class, condition category), manual price override authorization, statistical condition design, free goods condition type governance, pricing error detection
+  why_needed: Authoritative reference for assessing pricing procedure design and override control — defines the SAP SD pricing model and condition type framework used to classify pricing control findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP S/4HANA Sales — Credit Management
+
+- SAP S/4HANA Sales — Credit Management
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-sales/credit-management
+  source_owner: SAP SE
+  topic_supported: Credit control area configuration, credit limit assignment and governance, automatic credit check types (static check, dynamic check, maximum document value check), credit block reason design (reason A and B), credit block release authorization, SoD in credit management (sales order entry vs. credit limit authorization vs. credit block release)
+  why_needed: Primary reference for assessing credit management control design — defines the SAP S/4HANA credit management model, credit check configuration, and credit block authorization framework used to classify credit management findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP S/4HANA Sales — Billing and Billing Plan Configuration
+
+- SAP S/4HANA Sales — Billing
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-sales/billing
+  source_owner: SAP SE
+  topic_supported: Billing document type configuration (F1 order-based, F2 delivery-based, credit memo, debit memo), billing plan types (milestone billing plan, periodic billing plan), billing schedule design, SD–FI account determination for revenue and deferred revenue, billing due list management, unbilled delivery monitoring
+  why_needed: Defines the SAP SD billing and billing plan configuration model — required to assess billing cycle adherence, revenue recognition timing, and unbilled delivery revenue completeness findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP S/4HANA Sales — Availability Check and Fulfillment
+
+- SAP S/4HANA Sales — Availability Check and Transfer of Requirements
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-sales/availability-check-and-transfer-of-requirements
+  source_owner: SAP SE
+  topic_supported: ATP availability check configuration (checking rule, checking scope, replenishment lead time), transfer of requirements (TOR) design, delivery split logic and split criteria, partial delivery tolerance configuration, goods issue (GI) posting timing controls, fulfillment exception management
+  why_needed: Reference for assessing fulfillment exception management and availability check design — defines the ATP and TOR model used to classify delivery split, partial delivery tolerance, and fulfillment exception findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP FSCM — Dispute Management and Collections
+
+- SAP FSCM Dispute Management — Invoice Dispute Tracking and Resolution
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/dispute-management
+  source_owner: SAP SE
+  topic_supported: SAP Dispute Management configuration (dispute case type, reason code, status profile, processor assignment), dunning procedure configuration (dunning levels, dunning amounts, dunning interest, dunning escalation), cash application process design, deductions management, Days Sales Outstanding (DSO) analytics and receivables monitoring
+  why_needed: Defines the SAP FSCM Dispute Management and dunning model — required to classify DSO driver findings including dispute resolution cycle time, dunning process gaps, cash application delays, and deductions management deficiencies
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP S/4HANA Finance — Revenue Accounting and Reporting
+
+- SAP S/4HANA Finance — Revenue Accounting and Reporting
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/revenue-accounting-and-reporting
+  source_owner: SAP SE
+  topic_supported: IFRS 15 / ASC 606 revenue contract configuration, performance obligation design, standalone selling price assignment, revenue recognition event triggers, deferred revenue management, contract modification handling in SAP Revenue Accounting and Reporting (RAR)
+  why_needed: Reference for assessing revenue recognition completeness and IFRS 15 compliance controls — defines the performance obligation and recognition event model used to classify revenue timing and completeness findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP S/4HANA Sales and Finance documentation describes the designed configuration model and process options for Order-to-Cash. It does not prove what pricing conditions are active in the user's system, what credit block aging patterns exist, whether billing plan milestones are being met, or what the current DSO drivers are in the user's Accounts Receivable portfolio. Users must supply configuration descriptions, order block aging reports, billing schedule adherence data, credit management summaries, DSO analytics, dispute management reports, dunning procedure documentation, or written descriptions of their OTC landscape for concrete assessment.

package/skills/sap/sap-order-to-cash-review/references/safety-checklist.md

@@ -0,0 +1,39 @@
+# Safety checklist — SAP Order-to-Cash Review
+
+Use before making any OTC remediation recommendation, especially for findings involving zero-price sales order paths, credit block release SoD gaps, unbilled delivery revenue, billing plan slippage, or DSO drivers.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP S/4HANA Sales (SD) system, SAP S/4HANA Finance (FI) system, Fiori launchpad, SAP GUI session, backend RFC, or production OTC database. This skill reviews artifacts only.
+- Do not accept or request SAP logon credentials, RFC connection details, or direct OTC database access.
+- Do not create, modify, release, or cancel any sales order, delivery document, billing document, customer credit limit, or customer payment. There is no OTC document creation or mutation in this skill's execution path. Recommendations always describe configuration and process design changes, not direct document transactions.
+- Do not approve, close, or recommend closing an unmitigated critical OTC finding (zero-price revenue path; revenue account misposting at material level; credit block SoD gap with active exposure) without documented audit team and finance team authorization.
+- Do not recommend implementing OTC configuration changes (pricing procedure edits, credit check parameter changes, billing document type modifications, SD–FI account determination changes) directly in a production SAP S/4HANA system. All recommendations must first be tested in a non-production environment.
+- Do not use memory alone to assert what pricing condition types are active, what credit block aging looks like, whether billing plans are on schedule, or what the DSO drivers are in the user's OTC process. All findings must be grounded in user-provided artifacts or official SAP S/4HANA documentation.
+- Do not conflate a credit block (a system-generated hold pending credit management review) with a delivery block (a manually applied hold for operational reasons). They are governed by different authorization objects and represent different control risks. Distinguish clearly when classifying findings.
+
+## What people get wrong
+
+- **Treating pricing error indicators as self-correcting**: When a SAP SD pricing error indicator (pricing status I) is set on a sales order because a condition type could not be found, the order is not automatically blocked from delivery and billing. Unless a specific incompletion procedure or user exit enforces a block on pricing-error orders, they can proceed to fulfillment and invoice at zero or incorrect values. Reviews that check for pricing errors but do not verify that pricing-error orders are blocked miss the actual control gap.
+- **Overlooking the static vs. dynamic credit check distinction**: A static credit check (credit exposure at order creation vs. credit limit) does not update as deliveries and invoices are posted. A customer that passes the credit check at order creation may have their credit limit consumed by the time of delivery and billing. Organizations with high-value or long-cycle orders and a static-only credit check are monitoring a point-in-time exposure, not a real-time credit position.
+- **Conflating DSO calculation with DSO management**: DSO as a metric measures the average days to collect receivables. DSO as a management problem requires a driver analysis (billing cycle, dispute volume, dunning gaps, cash application delays). A review that only reports DSO elevation without a driver analysis does not provide actionable remediation direction.
+- **Missing the billing plan milestone slippage risk**: Milestone billing plans for project-based or multi-deliverable contracts require that billing dates are tied to project milestones, contract acceptance events, or delivery completions. If project delays push milestone dates without updating the billing plan, revenue recognition is deferred even when delivery value has been created. Billing plan milestone slippage is a common and underreported OTC revenue timing risk.
+- **Treating goods issue posting timing as a logistics issue only**: The timing of goods issue (GI) posting in SAP S/4HANA determines when inventory is relieved and when billing can be triggered for delivery-based billing documents. Delayed GI posting (posting GI days after physical shipment) adds preventable days to the billing cycle and to DSO. It is both a logistics execution and a revenue recognition process design issue.
+- **Overlooking unapplied cash in DSO analysis**: Customer payments sitting unapplied in the bank clearing or customer clearing account do not reduce the outstanding receivables balance in the aging report. High unapplied cash volumes systematically overstate DSO and can mask a well-performing collections process with a cash application process gap. DSO reviews that do not include clearing account aging miss this driver.
+- **Assuming order incompletion blocks downstream processing**: The SAP SD incompletion log flags missing data but does not automatically block fulfillment and billing unless a specific block is configured in the incompletion procedure. A review that confirms the incompletion procedure is configured but does not verify that missing required fields result in a delivery or billing block may overestimate the control effectiveness.
+
+## When to push back
+
+- Push back (and escalate to the audit and finance team) when a zero-price sales order path without a block is identified, or when revenue accounts are confirmed to be posting incorrectly at a material level — do not proceed with other recommendations until this is escalated.
+- Push back when a credit block SoD gap (order entry user can release their own credit block) is found — escalate to the GRC and audit team before any further credit decisions are made.
+- Push back when the user asks to confirm OTC control compliance from memory alone without providing order block aging reports, pricing procedure documentation, billing schedule adherence data, or credit management configuration summaries.
+- Push back when the request requires live SAP S/4HANA system access (SAP GUI session, RFC call, Fiori OData API) — state clearly that live inspection is out of scope and ask the user to supply the relevant exports or summaries.
+- Push back when asked to create sales orders, release order blocks, post billing documents, modify credit limits, or post customer payments — this is an absolute boundary and must be refused in all circumstances.
+- Push back when asked to approve or close an audit finding or revenue integrity risk without audit team and finance team authorization — this skill is advisory only.
+- Push back when the user presents only one OTC domain (e.g., only pricing or only DSO) as a complete OTC review — a meaningful OTC assessment requires coverage across order management, pricing, credit, billing, blocks, fulfillment, and DSO together.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP S/4HANA Sales and Distribution, SAP S/4HANA Finance Accounts Receivable, SAP FSCM Dispute Management, or SAP Help Portal OTC documentation, or SAP billing and revenue recognition guidance
+- `user-provided evidence` — order block aging reports, billing schedule adherence reports, pricing procedure documentation, credit management configuration summaries, DSO analytics, dispute management reports, dunning procedure documentation, unbilled delivery reports, or written descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled as such

package/skills/sap/sap-order-to-cash-review/references/workflow-and-output.md

@@ -0,0 +1,87 @@
+# Workflow and output contract — SAP Order-to-Cash Review
+
+Use this reference for all OTC finding classification, risk level assignment, remediation path selection, and output formatting.
+
+## OTC finding taxonomy
+
+| Domain | Finding class | Description |
+|--------|--------------|-------------|
+| `order-management` | `incompletion-procedure-gap` | Incompletion log (order incompletion procedure) does not cover a required field (ship-to party, requested delivery date, plant, price condition) — orders with missing data can proceed to fulfillment and cause downstream exceptions |
+| `order-management` | `document-type-over-permissive` | Sales order document type allows partner function combinations or organizational assignments that should be restricted for the given business process |
+| `pricing` | `override-without-approval` | Manual price override on a pricing condition type can be performed by the sales order entry user without a documented approval workflow — unauthorized discounting is possible without audit trail |
+| `pricing` | `zero-price-not-blocked` | Sales orders with a net value of zero (or below a minimum) can be saved and fulfilled without a system block or approval requirement — enables fraudulent or error-driven revenue leakage |
+| `pricing` | `pricing-error-not-blocked` | Pricing errors (condition type missing, access sequence not finding a valid condition record) result in an error indicator on the sales order but do not block the order from proceeding to delivery and billing — orders with pricing errors can be invoiced at zero or incorrect values |
+| `credit-management` | `credit-block-release-sod-gap` | The user or role that entered the sales order can also release the credit block on the same order — SoD gap in the credit risk control model |
+| `credit-management` | `credit-limit-override-uncontrolled` | Credit limits can be increased or set to a high threshold without a credit management approval workflow — credit exposure is not governed |
+| `credit-management` | `no-dynamic-credit-check` | Credit check is static (exposure vs. limit at order creation) rather than dynamic (updated with deliveries, billing, and open items) — credit exposure between order creation and invoice posting is not monitored |
+| `billing` | `unbilled-delivery-aging` | Goods issue has been posted but the delivery has not been invoiced within the standard billing cycle window — revenue recognition is delayed and represents a revenue completeness gap |
+| `billing` | `billing-plan-milestone-slippage` | Milestone billing plan dates are passing without billing being triggered — periodic or project revenue is being deferred beyond contractual and accounting policy timelines |
+| `billing` | `sd-fi-account-determination-gap` | SD–FI account determination (VKOA) is missing or incorrect for a revenue or deferred revenue account type — billing documents are posting to incorrect G/L accounts |
+| `order-blocks` | `aged-credit-block` | Credit-blocked orders are aging beyond the standard resolution target (typically 24–48 hours) without release or cancellation — material revenue at risk and customer experience impact |
+| `order-blocks` | `block-release-without-credit-review` | Credit blocks are being released by the sales team without a documented credit management review — credit control is bypassed |
+| `order-blocks` | `incompletion-block-pattern` | A pattern of incompletion blocks in a specific order type or sales organization indicates a systemic order entry quality issue, not a case-by-case data problem |
+| `fulfillment-exceptions` | `atp-check-not-configured` | Availability-to-promise (ATP) check is not configured for a material type or plant that requires it — orders for unavailable stock are confirmed without a realistic ship date |
+| `fulfillment-exceptions` | `uncontrolled-delivery-split` | Delivery split logic creates multiple delivery documents for a single sales order line without customer consent configuration — adds fulfillment cost and customer experience risk |
+| `fulfillment-exceptions` | `gi-posting-timing-gap` | Goods issue is not posted at the actual time of physical goods leaving the warehouse — revenue recognition and inventory accuracy are misaligned |
+| `dso-drivers` | `billing-cycle-timing-gap` | Billing is triggered significantly after goods issue rather than immediately — billing cycle timing is adding preventable days to DSO |
+| `dso-drivers` | `dispute-volume-unresolved` | SAP Dispute Management has a high volume of aged open dispute cases — unresolved disputes are converting to deductions and DSO elevation |
+| `dso-drivers` | `dunning-without-escalation` | Dunning procedure has insufficient levels or escalation amounts to prompt payment — late-paying customers receive dunning notices without meaningful consequence escalation |
+| `revenue-completeness` | `unapplied-cash-aging` | Customer payments are sitting in the clearing account unapplied beyond the standard cash application window — DSO is overstated and customer account balances are inaccurate |
+
+## Risk level assignment
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Sales orders processed at zero net value without block or approval (fraud enablement); credit block release SoD gap with material revenue or credit exposure; billing document posting to incorrect revenue accounts causing financial statement misstatement at a material level |
+| `high` | Manual pricing override without approval workflow; credit limit override without governance; unbilled delivery aging above materiality threshold; billing plan milestone slippage creating IFRS 15 / ASC 606 risk; no dynamic credit check with material order book exposure; aged credit blocks representing significant revenue at risk |
+| `medium` | Incompletion procedure gap causing fulfillment exceptions; ATP check gap for material-heavy order types; aged dispute cases creating deductions risk; billing cycle timing gap adding preventable DSO days; dunning without escalation for persistent late payers |
+| `low` | Best practice deviation in document type design or partner function configuration; minor delivery split configuration refinement; cosmetic billing plan date alignment |
+
+## Remediation path decision tree
+
+For each finding:
+
+1. **Is this a zero-price sales order path without a block, or a billing document posting to an incorrect revenue account at a material level?**
+   - Yes → `critical`. Immediately escalate to the audit and finance team. Implement a minimum value check on the incompletion procedure or a pricing completeness check blocking zero-net-value orders. Correct the SD–FI account determination for the affected billing document types in a non-production system first.
+   - No → continue.
+
+2. **Is this a credit block SoD gap where the sales order creator can also release the credit block?**
+   - Yes → `critical`. Escalate to the GRC and audit team. Redesign the credit block release authorization to require a separate credit management role distinct from the sales order entry role. Document the compensating control if immediate role redesign is not possible.
+   - No → continue.
+
+3. **Is this a pricing override without an approval workflow?**
+   - Yes → `high`. Implement a pricing override approval workflow in SAP S/4HANA. Require a secondary authorization (sales manager or pricing team) for manual overrides to net price condition types. Configure audit logging for all pricing overrides above a defined threshold.
+   - No → continue.
+
+4. **Is this an unbilled delivery aging or billing plan milestone slippage at a material scale?**
+   - Yes → `high`. Implement a daily unbilled delivery aging report with escalation to the billing team for items beyond the billing cycle target. Review billing plan milestone dates for alignment with contract terms. Configure the billing due list to automatically propose billing for overdue milestones.
+   - No → continue.
+
+5. **Is this a DSO elevation driven by dispute volume, dunning gaps, or cash application delays?**
+   - Yes → `high`. Diagnose the dominant DSO driver (dispute volume, cash application aging, dunning escalation gap). Configure SAP Dispute Management for the primary dispute reason codes. Add dunning escalation levels for persistent late payers. Establish a cash application SLA for remittance matching within one business day of payment receipt.
+   - No → classify as `medium` or `low` and provide guidance.
+
+## Workflow
+
+1. **Receive artifacts** — order block aging reports, billing schedule adherence reports, pricing procedure documentation, credit management configuration summaries, DSO analytics, dispute management reports, dunning procedure documentation, unbilled delivery reports, fulfillment exception reports, or written descriptions of the OTC landscape.
+2. **Classify each finding** by OTC process domain and finding class.
+3. **Assign risk level** per the table above (critical / high / medium / low).
+4. **Flag critical findings** immediately — zero-price sales order path, revenue account determination errors at material scale, and credit block SoD gaps must be escalated before other remediation.
+5. **Apply remediation decision tree** per finding.
+6. **Prioritize** — critical revenue integrity and SoD findings first; then high pricing override, credit limit governance, unbilled delivery, and billing plan slippage gaps; then medium incompletion, ATP, dispute, and dunning findings; then low best-practice items.
+7. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. OTC process domain and finding class per finding
+2. Evidence label (documentation-based / user-provided evidence / inference)
+3. Risk level per finding (critical / high / medium / low)
+4. Finding detail: affected sales order type, customer account, billing document type, credit control area, or OTC configuration object (if provided), and specific control or process gap
+5. Quantified revenue or DSO impact estimate where data is available (unbilled delivery value, billing plan slippage amount, DSO days attributable to identified driver, credit exposure at risk)
+6. Recommended remediation action (pricing override approval workflow, credit block SoD separation, unbilled delivery aging control, billing plan monitoring, SD–FI account determination correction, incompletion procedure extension, ATP check activation, dispute management configuration, dunning escalation addition, cash application SLA, etc.)
+7. OTC control posture after remediation
+8. Escalation notice for any critical zero-price revenue path or material revenue account misposting — explicit statement that this requires audit and finance team review before any further OTC transactions are processed
+9. Prioritized remediation sequence
+10. Confirmation that no sales orders were created or modified, no order blocks were released, no billing documents were posted, no credit limits were changed, and no customer payments were modified in this review