Having implemented both approaches in different contexts, here’s my comprehensive perspective on MCP servers versus custom APIs for intercompany automation:
MCP Governance and Compliance:
The governance concern is valid but solvable. Implement a structured logging framework where the MCP server records every decision point with full context. Each intercompany transaction should generate an audit record that includes: the natural language input, the interpreted intent, the validation steps performed, the API calls made, and the business rules applied. This creates a deterministic audit trail even though the orchestration is dynamic.
For compliance, implement a “validation gateway” pattern. The MCP server proposes transactions, but they must pass through a traditional rules engine that validates against your compliance requirements before execution. This separates the flexibility of MCP orchestration from the rigidity of compliance validation.
Custom API Flexibility:
Custom APIs excel in scenarios where transaction patterns are well-defined and stable. For intercompany automation, this means if your 12 legal entities follow consistent processes (standard PO-to-invoice-to-settlement flow), custom APIs provide better performance, clearer audit trails, and easier maintenance. The flexibility argument for MCP only matters if you frequently need to adapt to new intercompany scenarios without code deployments.
The real advantage of custom APIs is testing and validation. You can write comprehensive unit tests for every edge case. With MCP, testing becomes more complex because you’re testing intent understanding and orchestration logic, not just business rules.
Integration with Analytics:
This is where architecture becomes critical. Both approaches should emit events to a centralized analytics platform, but the event schemas differ:
Custom API events are straightforward: API endpoint called, parameters, response, duration. Your analytics can directly correlate these to business outcomes.
MCP events require richer context: original intent, interpretation confidence, orchestration decisions, API calls made, and outcome. You need to design your MCP server to emit structured events at each decision point, not just the final transaction. This creates a more complex analytics pipeline but provides insights into how the automation is interpreting and handling different scenarios.
Recommendation:
For intercompany transaction automation in D365 Finance, I’d recommend a hybrid approach:
-
Build custom REST APIs for core intercompany transactions (PO creation, invoice posting, settlement processing). These are your stable, well-tested, compliance-validated foundation.
-
Implement an MCP layer for workflow orchestration and exception handling. The MCP server understands user intent, determines which APIs to call in what sequence, and handles variations in approval workflows.
-
Use the MCP server for “last-mile” flexibility - handling scenarios like “create PO between Entity A and Entity B with expedited approval because it’s a critical vendor” without hardcoding every permutation.
-
Ensure all MCP decisions are logged with full context and validated against compliance rules before transaction execution.
-
For analytics integration, use an event-driven architecture where both custom APIs and the MCP server emit events to Azure Event Hub or similar. Your analytics platform consumes these events to provide visibility into transaction patterns, automation effectiveness, and exception trends.
The key insight is that MCP and custom APIs aren’t mutually exclusive. Use MCP for orchestration and flexibility, custom APIs for transaction execution and compliance. This gives you the governance and auditability required for financial transactions while maintaining the adaptability to handle variations in intercompany scenarios without constant code changes.