Indirect Tax Automation at Scale for Oracle Finance Systems

Challenge

A US-based FinTech company needed to improve a complex indirect tax processing workflow built around Oracle Finance systems and external tax services.

The integration landscape involved:

• Oracle Fusion using SOAP/XML services
• Oracle BIP for report-driven fiscal code retrieval
• Oracle UCM for file handling and output upload
• JSON-based tax service endpoints
• Both batch and on-demand execution paths

The major business and technical problems were:

1. Performance bottlenecks: Fiscal code retrieval through SOAP/BIP introduced high latency. In the earlier model, requests were handled too narrowly and too often, creating significant delays for large files.

2. Sequential processing limits: Too much of the workload was processed consecutively instead of concurrently, reducing throughput for high-volume runs.

3. Batch SLA risk: Observed runs projected several hours to completion in some scenarios, which was not acceptable operationally.

4. Integration complexity: The system had to bridge SOAP/XML Oracle interactions with JSON tax APIs, while preserving correctness in both directions and supporting the full processing loop.

5. Operational issues: The platform needed stronger controls for retries, logging, batch status, cache usage, memory pressure, and observability.

Approach

Kindl Labs focused on the performance-critical part of the integration flow and reworked the solution around batching, concurrency, caching, and safer operational controls.

The engineering approach included:

1. Isolate the primary bottleneck: Analysis showed the fiscal code retrieval path was a major source of delay, so it became the optimization target.

2. Introduce batch-oriented fiscal code retrieval: The design moved from narrow per-transaction behavior toward grouped batch retrieval before mapping.

3. Add concurrency and parallel execution: Parallel threads allowed multiple fiscal code retrieval requests to run concurrently during batch processing.

4. Add cache-first lookup behavior: The mapping flow reused already-retrieved fiscal data and called the source again only on cache miss.

5. Keep on-demand and batch behavior aligned: The solution supported both real-time on-demand flows and large batch processing.

6. Reduce operational overhead: Logging levels and flow behavior were tuned to lower runtime cost while preserving auditability and troubleshooting coverage.

Solution Architecture

This architecture was redesigned to keep fiscal-code retrieval, transformation, and tax-service calls coordinated while improving throughput and control.

                        +-----------------------------------+
                        |         Oracle Source Files       |
                        |      CSV / ZIP / Batch Input      |
                        +----------------+------------------+
                                         |
                                         v
                        +-----------------------------------+
                        |   ERP Integration Service Manager |
                        |  Batch Control / Orchestration    |
                        +----------------+------------------+
                                         |
                 +-----------------------+------------------------+
                 |                                                |
                 v                                                v
+-----------------------------------+          +-----------------------------------+
|   Fiscal Code Retrieval Pipeline  |          |      Transaction Mapping Flow     |
|  Oracle BIP SOAP/XML Requests     |          |   SOAP/XML <-> Canonical <-> JSON |
|  Batch IDs + Parallel Threads     |          |   Request/Response Transformation |
+----------------+------------------+          +----------------+------------------+
                 |                                                |
                 v                                                v
+-----------------------------------+          +-----------------------------------+
| Cache / Temporary In-Memory Store |          |     JSON Tax Service Endpoints    |
| Cache-first lookup during mapping |          |     Tax Calculation / Response     |
+----------------+------------------+          +----------------+------------------+
                 |                                                |
                 +-----------------------+------------------------+
                                         |
                                         v
                        +-----------------------------------+
                        |   Result Processing / Comments    |
                        |   Output Preparation              |
                        +----------------+------------------+
                                         |
                                         v
                        +-----------------------------------+
                        |        Oracle UCM Upload          |
                        |     Final Response / Closure      |
                        +----------------+------------------+
                                         |
                                         v
                        +-----------------------------------+
                        | Logging / Monitoring / Retry Flow |
                        | Batch Status / Failure Handling   |
                        +-----------------------------------+

Outcome

The project delivered a more scalable and performance-focused integration flow for indirect tax processing.

Documented and observed performance evolution from project notes:

• Early runs showed roughly 561 transactions in about 30 minutes, implying around 5 hours for full completion at that pace.
• A later observed state processed around 4,685 transactions in just over 45 minutes when fiscal code dependency was reduced in the critical path.
• Further optimization work, including caching and reduced logging overhead, brought end-to-end completion to about 45 minutes.
• In later tuned internal runs, the process was reported to complete in roughly 15 minutes end-to-end.

Practical business impact:

• Processing moved from multi-hour risk windows toward much faster batch turnaround.
• Manual intervention reduced significantly in normal runs.
• The architecture improved both throughput and operational control.
• The system became more suitable for enterprise-scale batch execution.

Kindl Labs helped transform a slow, tightly constrained tax-processing workflow into a scalable integration pipeline by reworking fiscal-code retrieval, introducing batching and concurrency, and improving cache utilization. Internal optimization runs moved the process from multi-hour projections to sub-hour execution, with later tuned runs reaching approximately 15 minutes end-to-end.

Technologies

• C#
• .NET
• SOAP/XML services
• JSON APIs
• Oracle Fusion
• Oracle BIP
• Oracle UCM
• In-memory caching
• Parallel processing / multi-threading
• NLog / application logging
• Batch orchestration patterns

Testimonial

“Kindl Labs helped improve both the performance and reliability of a highly complex integration flow. The solution reduced processing time significantly and gave us a much stronger operational footing for batch execution.”