ResolveOps

An AI agent that investigates failed EDI invoice pairings, explains the root cause, proposes a safe fix, and verifies the result after human approval.

Comment

ResolveOps

ResolveOps turns complex EDI and ERP invoice mismatches into clear, safe, operator-approved resolution workflows.

Inspiration

Many retailers still rely on employees to manually enter receiving documents and reconcile supplier invoices inside their ERP systems.

This creates frequent problems:

  • Invoice and receiving-document references are written differently
  • Invoices are linked to documents from the wrong store
  • ERP receiving documents are missing
  • Supplier item codes and EANs do not match
  • Invoice quantities are expressed in packages while ERP quantities are stored in pieces
  • Prices or quantities differ
  • Several documents or items appear to be plausible matches

Resolving these cases often requires opening several ERP screens, comparing records manually, understanding technical matching rules, and deciding whether a correction is safe.

I built ResolveOps to make that investigation faster without allowing AI to bypass accounting and inventory controls.

What it does

ResolveOps investigates EDI invoice exceptions using deterministic business rules and presents the result in a guided operator workflow.

It can:

  • Detect an invoice linked to a document from the wrong store
  • Detect when no ERP receiving document is linked
  • Search and rank ERP document candidates
  • Compare supplier, store, document reference, amount, VAT, and date
  • Compare invoice and ERP items
  • Match items through exact or alternate EANs
  • Recognize package-to-piece conversions
  • Detect quantity differences
  • Detect blocking price differences
  • Refuse automatic matching when candidates are ambiguous
  • Propose the next safe action
  • Require preview and explicit operator approval before a write action
  • Revalidate the current state before execution
  • Make execution idempotent
  • Verify the resulting state and retain an audit record

GPT-5.6 converts verified findings into a clear operator explanation, while deterministic backend rules remain authoritative for candidate eligibility, scoring, blocking conditions, and action availability.

Example document workflow

In the main demo, an invoice is linked to receiving document UMP-148, but the document belongs to the wrong store.

ResolveOps:

  1. Detects the store mismatch
  2. Explains the verified root cause
  3. Ranks possible replacement documents
  4. Identifies UMP-149 as the strongest valid candidate
  5. Prevents replacement pairing while the invalid relationship still exists
  6. Previews removal of the wrong relationship
  7. Requires explicit operator approval
  8. Revalidates, executes, and verifies the removal
  9. Refreshes the case into a No ERP document state
  10. Enables the valid replacement action
  11. Previews, approves, and creates the new relationship
  12. Verifies that the invoice is correctly linked and marks the case resolved

The case progresses through visible states:

Wrong store pair → No ERP document → Resolved

Item-level reconciliation

ResolveOps also demonstrates realistic item-level reconciliation.

Safe package conversion

The supplier invoice contains:

  • 5 packages
  • 10 pieces per package
  • $50.00 per package

The ERP receiving document contains:

  • 50 pieces
  • $5.00 per piece

ResolveOps verifies:

  • Quantity: (5 \times 10 = 50) pieces
  • Normalized price: (10 \times \$5.00 = \$50.00) per package

The quantity and normalized price therefore match safely.

Blocking price difference

In another scenario, the invoice price is higher than the ERP price beyond the permitted tolerance.

ResolveOps displays:

  • Invoice price
  • ERP price
  • Absolute difference
  • Percentage difference
  • Blocking status

The system does not automatically accept or reject the difference. It requires operator review.

Ambiguous item match

When an invoice item has no usable EAN and two ERP items are plausible, ResolveOps refuses to guess.

Product-name similarity may be shown as supporting evidence, but it is never sufficient by itself for an automatic match.

The operator sees the available candidates and a clear Manual selection required state.

Safety model

ResolveOps deliberately separates AI assistance from operational authority.

The language model may explain verified evidence, but it cannot:

  • Issue SQL
  • Invent a document or item candidate
  • Change deterministic scores
  • Select an ineligible candidate
  • Override a blocking mismatch
  • Execute an action directly
  • Claim that an action succeeded before verification

Write operations follow this sequence:

Analyze → Preview → Approve → Revalidate → Execute → Verify → Audit

This keeps the operator in control and makes each change traceable.

How I built it

ResolveOps uses:

  • ASP.NET Core for the backend
  • React, TypeScript, and Vite for the operator dashboard
  • Synthetic JSON data for a safe demonstration
  • Deterministic matching and safety services
  • OpenAI Responses API for operator-facing explanations
  • Structured outputs with a defined JSON schema
  • In-memory preview, approval, execution, verification, and audit services
  • Automated frontend and backend tests

The Build Week version uses synthetic, in-memory data and resets when the API restarts.

It does not connect to a production ERP database. However, its models, exception types, and safety workflow were derived from real retail EDI and invoice-reconciliation scenarios.

The application also works without API credits: when OpenAI is disabled or unavailable, ResolveOps returns a deterministic fallback explanation and preserves the full workflow.

How I used Codex

I used Codex throughout implementation.

Codex helped me:

  • Inspect and understand the repository
  • Create and modify the .NET and React code
  • Implement services and API endpoints
  • Build the operator dashboard
  • Refactor state management
  • Diagnose layout and synchronization problems
  • Add regression tests
  • Run and verify frontend and backend builds
  • Keep coordinated backend models, frontend types, API clients, and tests aligned

How I used GPT-5.6

I used GPT-5.6 as an architecture and product-development partner.

GPT-5.6 helped me:

  • Translate a real invoice-processing workflow into a safe agent architecture
  • Separate deterministic decisions from AI explanations
  • Design document and item candidate scoring
  • Define approval, execution, verification, and audit boundaries
  • Review real matching and reconciliation rules
  • Identify unsafe or misleading UX behavior
  • Design realistic synthetic test cases
  • Plan implementation in controlled stages
  • Debug state synchronization and action ordering
  • Improve operator-facing terminology and explanations

Inside ResolveOps, the model explains verified evidence and recommended next steps. It cannot change deterministic scores, eligibility, blocking status, or execute actions directly.

Challenges

The hardest part was not generating an AI explanation. It was deciding where AI should stop.

Invoice reconciliation affects inventory, supplier balances, and accounting records. A confident but incorrect recommendation can be expensive.

The project required a strict separation between:

  • Model-generated narrative
  • Deterministic evidence
  • Candidate eligibility
  • Operator approval
  • State-changing execution
  • Post-execution verification

Another challenge was demonstrating realistic ERP complexity without exposing production or company data. I therefore created synthetic scenarios that preserve the important matching and safety behavior.

Accomplishments

I am proud that ResolveOps is more than a chatbot over invoice data.

It includes:

  • Document-level investigation
  • Ranked document candidates
  • Item-level reconciliation
  • Exact and alternate EAN handling
  • Safe package conversion
  • Blocking price controls
  • Ambiguous-match refusal
  • Live case-state transitions
  • Explicit operator approval
  • Idempotent execution
  • Post-action verification
  • Audit history
  • Deterministic fallback when the OpenAI API is unavailable
  • Automated frontend and backend test coverage

What I learned

The most important lesson was that AI is most useful in this workflow when it improves understanding and navigation—not when it replaces accounting controls.

A good operational agent should know:

  • Which decisions are deterministic
  • Which actions require human approval
  • Which situations are too ambiguous to automate
  • Which results must be verified after execution

I also learned that operator experience matters as much as the matching algorithm. A technically correct result is not useful if employees cannot quickly understand what happened and what they are expected to do next.

What is next

The next stage would connect ResolveOps to controlled production API gateways rather than giving the agent direct database access.

Future capabilities could include:

  • Real invoice and receiving-document retrieval
  • Supplier-specific matching policies
  • Broader document-reference normalization
  • Historical operator-feedback analysis
  • More advanced many-to-many item reconciliation
  • Store correction notifications
  • Price-decision workflows
  • Monitoring of unresolved exceptions
  • Evaluation of candidate-ranking quality against historical cases
  • Persistent audit storage

The long-term goal is to reduce manual reconciliation work across many stores while keeping every operational change explainable, controlled, and auditable.

Built With

Share this project:

Updates

Submission history