Engineering & Construction Case Study
Automating Accounts Payable & Accounts Receivable for Finance Operations
Integrating a Facilities Management Platform and Oracle JD Edwards ERP
The client, a national engineering and construction services provider, manages facilities maintenance, capital projects, and specialty trade work across a large portfolio of commercial sites. Their field work orders, vendor invoicing, and customer billing were managed through a 3rd party cloud-based work order and facilities management platform. Meanwhile, all core financials — accounts payable, accounts receivable, and the general ledger — lived in JD Edwards EnterpriseOne (JDE).
The two systems had no native integration, which meant every invoice and every customer bill required manual re-entry between platforms.
Below, we’ll take a look at the requirements, challenges and solution architecture and how we approached them. Do you feel like you’re in the same boat? Book time with an expert on this project and we’ll provide some guidance.
Business Requirements
Eliminate manual re-entry while preserving controls and audit trail
The client’s finance and operations teams needed a way to eliminate that manual re-entry while preserving the controls and audit trail JDE provides. The core requirements were:
Technical Challenges
Navigating a complex integration initiative
Mapping Two Very Different Data Models
The 3rd party vendor platform organizes data around work orders, locations, and specialties (trade categories such as electrical, janitorial, or landscaping). JDE organizes data around ledgers, batches, and GL accounts (F0411 for AP, F03B11 for AR, F0911 for the general ledger).
Translating between the two required a detailed field-by-field mapping — for example, a work order’s “unique ID” and “external work order” fields had to be written into specific, often reused, GL ledger columns that JDE customers typically use for other purposes. Every mapping decision had to be validated against how the client’s finance team actually used those fields, to avoid silently overwriting data they depended on elsewhere.
No Out-of-the-Box Connector
JDE EnterpriseOne does not ship with a native connector for third-party facilities management platforms. The integration had to be built using JDE’s Orchestrator framework — a low-code but still intricate tool for exposing JDE’s business functions (like voucher entry and standard invoice entry) as REST APIs. Each orchestration had to correctly sequence multiple underlying JDE forms (Work With Batches, Voucher/Invoice Entry, GL Distribution) as a single atomic transaction, so a partial failure wouldn’t leave a batch half-posted.
Multi-Entity and Subsidiary Account Complexity
The client operates through more than one legal entity and uses subsidiary codes to distinguish planned, quoted, project, and reactive work types. The integration needed a maintainable cross-reference (built as custom JDE UDCs and custom tables) mapping the 3rd party vendor’s specialties and work order types to the correct JDE entity, GL subsidiary, and specialty category — rather than hard-coding those relationships into the orchestrations themselves, which would have made future changes a code change instead of a configuration change.
AR Was Materially Harder Than AP
While the AP orchestration reached a stable, fully working state, the AR orchestration remained under active development throughout the engagement. Certain AR fields could not be reliably updated through the standard JDE invoice entry function once a transaction was already posted, which meant some corrections had to fall back to manual GL adjustment rather than a clean API update. This is a common pattern in AP/AR integrations: AP transactions are typically simpler, single-sided postings, while AR transactions interact with customer-facing billing rules, tax dates, and completion dates that carry more downstream implications.
Traceability Across Systems
Every JDE voucher and invoice needed to be traceable back to the originating work order in the 3rd party vendor platform, and vice versa. The team standardized on carrying the work order ID and type through to specific JDE ledger fields (as an “external work order” and “external work order type” pair) on every GL line, so a finance user could query JDE’s data browser and immediately identify the source system record without a separate lookup table.
Deriving Cost Center from Complex Business Rules
The cost center (business unit) for each transaction could not simply be passed through from the 3rd party vendor platform — it had to be derived at run time from a combination of entity, location, and specialty values, applying business rules that varied by legal entity. This logic had to live inside the orchestration itself, since JDE’s standard entry programs expect a resolved cost center as input rather than the raw attributes needed to calculate one.
Deriving the Cost Account for Each Distribution Line at Run Time
Similarly, the GL object account for each distribution line could not be hard-coded or passed statically. It had to be resolved dynamically, line by line, based on the specialty and work type associated with that portion of the work order — meaning the orchestration effectively had to replicate account-derivation logic that would normally live in a person’s head or a manual coding sheet.
Splitting Invoices That Exceed JDE’s Line-Item Limit
JDE’s standard AR invoice entry program (P03B11) does not support more than 999 line items on a single invoice. Some work orders from the 3rd party vendor platform generated invoices with far more distribution lines than that, so the orchestration had to detect when a source invoice would exceed the limit, split it into multiple JDE invoices, and post all of the resulting invoices under a single batch — so that, from a reconciliation standpoint, they still read as one originating transaction.
Working Around an Older Orchestrator Version Without Logic Extensions
The JDE Orchestrator version available in this environment did not support logic extensions, a feature that in newer JDE releases allows custom conditional logic to run inside an orchestration. Without it, the cost center derivation, cost account derivation, and invoice-splitting logic described above all had to be engineered using the more limited set of steps, rules, and conditional branches available in that older version — a meaningfully more constrained toolkit to build multi-step business logic with.
Reformatting an Incompatible Input Payload
The payload coming from the 3rd party vendor platform was not directly compatible with the structure JDE’s invoice entry application expects — field names, groupings, and data types differed enough that a straight pass-through was not possible. A transformation step had to reshape the incoming payload into the exact structure JDE’s orchestration required before any of the entry or distribution logic could run, adding another layer that had to be built and validated alongside the core posting logic.
Solution Architecture
The integration was built around two JDE Orchestrator-based REST endpoints
Supporting both orchestrations, the team built custom JDE cross-reference tables that hold the specialty-to-GL-subsidiary mapping and the work-order-type-to-subsidiary mapping. This kept the field-level business logic in configuration tables that the client’s own JDE administrators can maintain, rather than in code that would require a developer for every new specialty or work order type.
Each orchestration returns structured status metadata (success/failure, start and end timestamps, and server execution time), which finance operations uses to monitor throughput and quickly flag any transaction that didn’t post cleanly.
The outcome of connecting a modern SaaS operations platform to a mature ERP
With the integration in place, the client’s finance team no longer manually re-keys vendor invoices or customer bills between the 3rd party vendor platform and JDE. AP vouchers post automatically with full GL distribution and a traceable work order reference; each transaction can be reconciled in JDE’s standard batch and ledger tools within seconds of being triggered. The AR side is on the same trajectory, with the core orchestration proven out and a defined path to close the remaining gaps in field-level updates.
The Smartbridge team was a strong partner throughout a complex integration initiative. They combined a solid understanding of JD Edwards Orchestrator with a practical approach to translating detailed financial and operational requirements into a workable solution.
The team was collaborative, responsive, and easy to work with, demonstrating the flexibility to work directly with our internal team as well as alongside our third-party software vendor to align technical requirements and translate them into a cohesive integration design.
~ Client Senior Director
More broadly, the project illustrates what it actually takes to connect a modern SaaS operations platform to a mature ERP like JD Edwards.
Not just moving data from one API to another, but reconciling two fundamentally different data models, respecting the ERP’s existing chart of accounts and controls, and building the cross-reference and monitoring layers that let a finance team trust an automated integration enough to rely on it every day.
