Bank reconciliation can be challenging enough when transactions match neatly between financial systems and bank statements. When thousands of electronic payments, multiple departments, third-party payment processors, and inconsistent transaction details enter the picture, traditional reconciliation methods become significantly more complicated.

At INFOCUS 2026, Aprille Moyster shared how Allegheny County, Pennsylvania, is using JD Edwards EnterpriseOne Orchestrator to tackle these challenges. In her session, “Practical Orchestrations: Logic Extensions, Connectors, and Buttons,” Moyster demonstrated how logic extensions, orchestration connectors, and EnterpriseOne (E1) buttons can transform complicated manual processes into repeatable, user-friendly workflows.

Her experience offers practical lessons for organizations looking to improve JD Edwards bank reconciliation automation, reduce processing time, and give business users greater control without extensive application customization.

Closing the Gap Between Financial Records and Bank Statements

Allegheny County operates a substantial JD Edwards environment supporting financials, procurement, job costing, fixed assets, payroll, and human resources. With approximately $2 billion in annual revenue and thousands of monthly transactions, reconciling financial activity requires coordination across multiple departments and systems.

Historically, the county’s Treasurer’s Office handled banking activity through a separate cash management system, while the Controller’s Office maintained financial records in JD Edwards. Although the Treasurer’s Office reconciled its records to the bank, the Controller’s Office was reconciling JD Edwards against the Treasurer’s records rather than directly against bank statements.

This created a gap in the county’s book-to-bank reconciliation process.

To address it, the team began importing BAI2 bank statement files into JD Edwards and implementing standard reconciliation capabilities. This also provided an opportunity to consolidate bank statement reporting that had previously been maintained across separate Excel files.

However, electronic payments presented additional challenges. While standard functionality could accommodate many check transactions, ACH payments and wire transfers often lacked straightforward matches between the bank statement and JD Edwards.

Why Electronic Payment Reconciliation Required a Different Approach

Moyster explained that electronic payments rarely followed a consistent one-to-one matching pattern. Some bank transactions represented multiple JD Edwards payments, while others required information embedded in descriptions, invoice numbers, or user-defined fields to identify corresponding records.

Rather than attempt to create one universal matching rule, she developed separate logic extensions to handle different transaction scenarios.

For example, certain payments could be reconciled using general ledger dates or voucher invoice numbers. Federal income tax and FICA payments, maintained under separate vendors, could be combined into a single matching amount.

More complicated scenarios involved the county’s Department of Human Services. Payments to foster care providers and senior companions were processed through a third-party debit card provider. Although individual recipients were maintained as vendors in JD Edwards, the bank statement reflected lump-sum transfers to the payment processor.

To reconcile those transactions, Moyster used a user-reserved code field to identify and aggregate payments by category. When that field was missing from some uploaded records, she incorporated vendor search types from address book data to identify the correct transactions.

Other reconciliations required extracting payment numbers embedded in transaction descriptions or manipulating invoice numbers to combine related amounts. One Pennsylvania sales tax example involved identifying invoices with A and B suffixes, removing those suffixes, and aggregating the appropriate payments before comparing them against the bank statement.

These examples illustrate an important principle: effective reconciliation automation depends on understanding how transactions are actually recorded and processed, not simply matching amounts.

Using Logic Extensions to Handle Complex Matching Rules

Logic extensions became a central component of Allegheny County’s reconciliation solution after its move to JD Edwards Tools Release 9.2.7.

Previously, more complex processing often required Groovy scripts. Logic extensions provided another way to perform calculations, manipulate strings, apply conditional rules, and aggregate data through Orchestrator Studio.

Moyster relied heavily on aggregation to group transactions and prepare amounts for reconciliation. One particularly useful discovery was that multiple aggregation components could append results to the same array when mapped appropriately. This allowed her to combine different payment categories without creating entirely separate output structures.

She also found that some operations were easier to accomplish through a JD Edwards business view. When she needed to join transaction information with address book search types, creating a business view proved more manageable than building complicated nested loops within logic extensions.

The approach wasn’t entirely without challenges. Moyster acknowledged that logic extensions have a learning curve, particularly when handling arrays, nested processing, and input/output mappings. Nevertheless, their testing and debugging capabilities made it easier to inspect intermediate results and troubleshoot complex reconciliation rules.

Reducing Processing Time from Seven Hours to 20 Minutes

One of the session’s most compelling takeaways was the dramatic improvement in reconciliation processing time.

Allegheny County’s reconciliation processing time

Approximately 95% less processing time from the original implementation.

The initial orchestration took approximately seven hours to complete. Much of that overhead came from updating large volumes of records through form service requests.

By switching to direct table updates for the appropriate reconciliation fields and streamlining processing logic, Moyster reduced execution time to approximately 40 minutes.

She then observed another improvement after incorporating individual orchestrations as connectors, bringing the total processing time down to approximately 20 minutes. During the session’s discussion, attendees questioned why this change alone would improve performance, and the technical explanation remained unresolved. The improvement was observed in her implementation rather than established as a universal performance benefit of connectors.

Moyster also emphasized the importance of using conditional rules to exit unnecessary processing loops, limiting the records evaluated, and designing orchestrations around the most efficient starting dataset.

For reconciliation, she began with bank statement debits rather than the substantially larger number of JD Edwards transactions, reducing the volume of records requiring evaluation.

Making Automation Accessible Through E1 Buttons

Despite the performance improvements, a 20-minute reconciliation process was still too long for users to wait for immediate results.

Moyster addressed this by creating an E1 button within the bank statement reconciliation application. Users enter a date range and initiate the process directly from JD Edwards. The orchestration then runs in the background, with email notifications confirming when processing starts and finishes.

Notifications also go to the help desk, providing visibility into resource-intensive activity. This was particularly important because Moyster had previously experienced system problems when too many operations were running simultaneously.

The reconciliation solution now includes more than 50 components, with multiple levels of nested orchestrations. Its modular design allows additional reconciliation rules to be developed, tested independently, and incorporated as new transaction scenarios are addressed.

This scalability is especially valuable for organizations that cannot automate every reconciliation scenario at once. Allegheny County began with relatively straightforward, high-volume opportunities and expanded the solution incrementally.

Applying the Same Principles to Payroll Validation

Moyster also demonstrated how the same Orchestrator capabilities could address an entirely different operational challenge: payroll validation.

Allegheny County processes payroll across 32 departments and more than 6,000 employees. Before final payroll processing, temporary tables must be checked for records that could interfere with calculations.

Previously, a third-party reporting solution performed these checks, but the process required approximately five minutes and delivered results through email. On one occasion, users proceeded without reviewing the report, contributing to payroll calculation problems.

Moyster replaced that workflow with an E1 button in the payroll workbench. Payroll analysts can enter their department’s payroll ID and check date, then receive immediate feedback about whether relevant temporary tables are clear.

The orchestration checks selected tables, validates the payroll ID to prevent false-positive results, and stops processing when it identifies a problem. The check takes approximately 30 seconds.

Importantly, the button identifies potential problems without automatically deleting records. Detailed reporting remains available to determine which tables require attention.

The example demonstrates how Orchestrator can improve not only processing efficiency but also the timing and accessibility of operational controls.

Practical Lessons for JD Edwards Orchestrator Development

Throughout the session, Moyster shared lessons learned while building and refining these solutions.

One recurring challenge involved managing dependencies. When an orchestration contains dozens of components, every required object must be properly shared, including the form extension supporting an E1 button. Missing dependencies can prevent users from accessing functionality even when the orchestration itself works correctly.

She also stressed the importance of verifying input and output mappings, particularly when working with arrays and aggregation. Incorrect mappings can make valid processing logic appear broken.

For more specialized calculations, Groovy scripts remain useful. Moyster described using a short script to calculate a particular historical date that would have been cumbersome to derive through logic extensions. However, she noted that Oracle does not provide support for Groovy scripts themselves, making maintainability an important consideration.

Her broader advice was to choose the appropriate tool for each task, test individual components carefully, and avoid unnecessary complexity.

Building Automation Around Real Business Processes

Allegheny County’s experience demonstrates that JD Edwards bank reconciliation automation doesn’t require every transaction to follow the same rules. By combining targeted logic extensions, reusable orchestrations, carefully designed matching criteria, and accessible E1 buttons, organizations can address reconciliation scenarios that initially appear too complicated to automate.

The results extend beyond the reduction from seven hours to 20 minutes. The county has established a foundation for expanding reconciliation coverage while reducing manual work, improving consistency, and giving users more direct access to essential financial processes.

For JD Edwards teams exploring Orchestrator, Moyster’s message is clear: start with a practical business problem, understand the underlying data, and build automation incrementally. Even the most complicated processes become more manageable when broken into smaller, testable components.

Want more?

Explore more content and resources to help you get the most from your JD Edwards investment:

• Visit the Quest Learn Library for blogs, how-to demos, and on-demand sessions.
• Connect with peers in one of our Quest JD Edwards Community User Groups to swap stories, ask questions, and share tips with other users facing the same challenges.
• Bookmark LearnJDE.com for updates from JD Edwards development.

Not a Quest member yet? Join today and tap into the ultimate Oracle customer network.