close

DEV Community

Irvan Gerhana Septiyana
Irvan Gerhana Septiyana

Posted on

Building a Reconciliation Engine for Enterprise AI Systems

#ai #datascience #automation #showdev

Part 5 of the Building Enterprise AI Automation Systems Series

Introduction

Artificial Intelligence has dramatically improved how machines understand unstructured information.

Modern language models can extract entities from documents.

Named Entity Recognition systems can identify invoices, contracts, customers, and payment references.

Entity Resolution engines can map those entities to master records.

Many AI tutorials stop here.

The extracted entities are displayed.

The demo ends.

However, enterprise automation has only completed the first half of the journey.

Understanding information is not the same as making business decisions.

Imagine an AI model successfully extracts the following entities:

{
    "customer_id":"CUS-00002",
    "invoice_number":"MFG-INV-000157",
    "contract_id":"CNT-2024-587",
    "amount":3979.85
}
Enter fullscreen mode Exit fullscreen mode

Can the transaction be reconciled?

Not necessarily.

A business still needs to answer questions such as:

  • Does the invoice exist?
  • Is the invoice already paid?
  • Does the invoice belong to this customer?
  • Is the payment amount correct?
  • Is partial payment allowed?
  • Has the contract expired?
  • Is manual approval required?

These questions are not language problems.

They are business problems.

This is where the Reconciliation Engine becomes the heart of enterprise automation.

Understanding Reconciliation

Many people associate reconciliation with matching numbers.

In reality, reconciliation is the process of validating business relationships.

A payment is not considered reconciled simply because the amount matches.

It must also satisfy business constraints.

For example:

Customer
↓

Contract
↓

Invoice
↓

Payment
Enter fullscreen mode Exit fullscreen mode

Every relationship must be validated.

A payment that references the correct invoice but belongs to the wrong customer is still incorrect.

Business context always matters.

Why AI Alone Is Not Enough

Large Language Models are excellent at understanding text.

They are not designed to enforce financial policies.

Suppose an AI model predicts:

{
    "invoice":"MFG-INV-000157"
}
Enter fullscreen mode Exit fullscreen mode

Should the invoice automatically be marked as paid?

No.

The AI has identified an invoice.

It has not validated the business.

Validation requires deterministic logic.

Enterprise software depends on deterministic behavior.

This is why rule engines continue to play a critical role in modern AI architectures.

Designing the Reconciliation Pipeline

Our reconciliation pipeline consists of several independent stages.

Bank Statement
        │
        ▼
Canonical Transformation
        │
        ▼
Named Entity Recognition
        │
        ▼
Entity Resolution
        │
        ▼
Business Validation
        │
        ▼
Decision Engine
        │
        ▼
Reconciliation Result
Enter fullscreen mode Exit fullscreen mode

Each stage contributes information.

Only the Decision Engine determines the final outcome.

Business Validation Rules

The Decision Engine evaluates multiple business constraints.

Instead of asking a single question, it evaluates many.

Customer Validation

Does the payment belong to the expected customer?

Example:

Payment

↓

ALPHABRIDGE SOLUTIONS

↓

Invoice Owner

↓

ALPHABRIDGE SOLUTIONS

↓

PASS
Enter fullscreen mode Exit fullscreen mode

Invoice Validation

Does the invoice exist?

Invoice

↓

MFG-INV-000157

↓

Invoice Database

↓

FOUND
Enter fullscreen mode Exit fullscreen mode

Contract Validation

Does the invoice belong to an active contract?

Invoice

↓

Contract

↓

Status

↓

ACTIVE
Enter fullscreen mode Exit fullscreen mode

Amount Validation

Does the payment amount satisfy business expectations?

Possible scenarios include:

Exact Payment
Enter fullscreen mode Exit fullscreen mode 
Partial Payment
Enter fullscreen mode Exit fullscreen mode 
Overpayment
Enter fullscreen mode Exit fullscreen mode 
Underpayment
Enter fullscreen mode Exit fullscreen mode

Different organizations implement different policies.

The Decision Engine should support configurable rules.

Currency Validation

Example:

Invoice

EUR
Enter fullscreen mode Exit fullscreen mode

Payment

USD
Enter fullscreen mode Exit fullscreen mode

Automatic reconciliation should probably stop.

Duplicate Payment Detection

A second payment for the same invoice may indicate:

  • duplicate transfer
  • accounting error
  • fraud
  • intentional split payment

The engine must detect these situations before reconciliation.

Decision Categories

Instead of returning only True or False, the engine produces business decisions.

For example:

AUTO_RECONCILED
Enter fullscreen mode Exit fullscreen mode

Everything is valid.

No human intervention required.

PARTIAL_PAYMENT
Enter fullscreen mode Exit fullscreen mode

Invoice remains open.

Outstanding balance exists.

OVERPAYMENT
Enter fullscreen mode Exit fullscreen mode

Customer paid more than expected.

Refund or credit note may be required.

UNDERPAYMENT
Enter fullscreen mode Exit fullscreen mode

Payment received.

Invoice remains partially unpaid.

MULTIPLE_INVOICES
Enter fullscreen mode Exit fullscreen mode

One transaction settles multiple invoices.

REVIEW_REQUIRED
Enter fullscreen mode Exit fullscreen mode

Business confidence is insufficient.

Escalate to finance.

These decisions become the language of downstream automation.

Rule Engine Design

A common misconception is that rule engines are obsolete.

The opposite is true.

AI identifies possibilities.

Rules enforce certainty.

A simplified evaluation flow looks like this:

Invoice Exists?

↓

NO

↓

REVIEW_REQUIRED
Enter fullscreen mode Exit fullscreen mode 
Customer Match?

↓

NO

↓

MANUAL_REVIEW
Enter fullscreen mode Exit fullscreen mode 
Amount Correct?

↓

YES

↓

AUTO_RECONCILED
Enter fullscreen mode Exit fullscreen mode

Notice that every decision is deterministic.

No hallucinations.

No ambiguity.

Exactly what enterprise software requires.

Confidence-Based Decisions

Not every prediction should trigger automation.

Suppose Entity Resolution returns:

{
    "customer_id":"CUS-00002",
    "confidence":0.98
}
Enter fullscreen mode Exit fullscreen mode

Automatic reconciliation is probably acceptable.

Now imagine:

{
    "customer_id":"CUS-00017",
    "confidence":0.54
}
Enter fullscreen mode Exit fullscreen mode

Should the ERP be updated?

Probably not.

Confidence thresholds allow organizations to balance automation with operational risk.

For example:

Confidence ≥ 0.95

↓

Automatic Processing
Enter fullscreen mode Exit fullscreen mode 
Confidence ≥ 0.80

↓

Human Verification
Enter fullscreen mode Exit fullscreen mode 
Confidence < 0.80

↓

Manual Review
Enter fullscreen mode Exit fullscreen mode

This approach dramatically reduces costly reconciliation mistakes.

Building Explainable Decisions

One advantage of rule-based reconciliation is explainability.

Instead of returning:

Rejected
Enter fullscreen mode Exit fullscreen mode

The engine should explain why.

Example:

{
    "status":"REVIEW_REQUIRED",
    "reason":"Invoice amount does not match payment amount."
}
Enter fullscreen mode Exit fullscreen mode

Or:

{
    "status":"PARTIAL_PAYMENT",
    "remaining_balance":620.50
}
Enter fullscreen mode Exit fullscreen mode

Explainability increases trust.

Finance teams are far more likely to adopt AI systems that justify their decisions.

Integrating AI with Business Rules

One of the most important architectural lessons from this project is that AI should not replace business rules.

Instead, AI should enrich them.

Think of the relationship like this.

NER

↓

Extracts Business Entities

↓

Entity Resolution

↓

Identifies Business Objects

↓

Business Rules

↓

Evaluates Policies

↓

Decision Engine

↓

Determines Outcome

↓

Automation
Enter fullscreen mode Exit fullscreen mode

Every layer has a single responsibility.

This separation makes systems easier to test, explain, and maintain.

Lessons Learned

Building the reconciliation engine fundamentally changed how I think about enterprise AI.

Initially, I assumed machine learning would solve most of the problem.

Instead, machine learning solved understanding.

Business rules solved trust.

This distinction became one of the most valuable lessons in the project.

Organizations rarely automate because they understand language.

They automate because they trust decisions.

Trust comes from deterministic validation.

Not prediction alone.

Conclusion

Artificial Intelligence is exceptionally good at understanding documents.

Enterprise software, however, must also enforce policies.

A reconciliation engine bridges these two worlds.

It transforms extracted entities into validated business decisions.

By combining AI with deterministic business logic, organizations can automate financial operations without sacrificing reliability, auditability, or explainability.

The future of enterprise automation is therefore not AI versus rules.

It is AI working together with rules.

What's Next?

Part 6 — Building a Transaction Intelligence API with FastAPI

In the next article, we'll expose the entire pipeline as a production-ready REST API.

We'll cover:

  • Designing clean API contracts
  • Request and response schemas
  • Inference pipelines
  • Streaming predictions
  • Error handling
  • Confidence reporting
  • Production deployment with FastAPI

We'll transform our Transaction Intelligence pipeline into a service that ERP systems, finance platforms, AI agents, and enterprise applications can consume in real time.

Top comments (0)