The front door to AI in your organisation.

One chat across every SAP system you run — ECC, S/4HANA, BTP and beyond. Grounded in your landscape, not rented from public tools.

A brief for delivery partners and their clients
Scroll
One chat.
Every system — including ECC.

Every assistant SAP ships is built for the cloud you have not moved to yet. ireya reads ECC too — so the estate that most needs work is the one it can read today.

And it does not stop at SAP: one chat across every system and client you run, instead of an assistant per box.

The shift already happened

AI chat has become the way people reach AI.

Your people already use AI every day — through tools that know nothing about your business.

Today: public AI

  • Knows the internet — not your business
  • Staff paste internal data to get help
  • Every team solves AI alone, from zero
  • You rent the entry point

With ireya

  • Understands your systems, code and documents
  • Data stays inside your estate
  • One central chat for every SAP system
  • You own the entry point
The core insight

The model is a commodity.
Context is the value.

Everyone buys the same models. Nobody can buy a live connection to your systems, data and processes. That connection is the moat.

Same models, everyone

Available to any company. The AI itself is not a differentiator.

Your context, only you

A live link to your own landscape, ECC or S/4HANA. No public tool can offer it.

Proven in production

Reading real ABAP code and SAP objects in a live landscape today.

See it work

What a session looks like.

Eight questions in one thread — understand, predict, decide, and finish holding a document you can send. Capabilities are real; names and figures are examples, not one customer's system.

What's New v2.8.115 Feedback & Tickets RYRay Yeap

Good afternoon, Ray Yeap

What are we working on?

Explain what program ZFGLEU001 does in plain English

ZFGLEU001 is a month-end GL reconciliation report. It reads the FI documents posted for a company code and fiscal period, compares them against the general ledger balances, and lists every difference it finds.

It readsIt writes
BKPF, BSEG — document header and line itemsA spool list, one line per difference
SKAT — GL account descriptionsZFI_RECON_LOG — a run history

One selection screen, no user interaction, and it runs nightly in the background. In short: it is the report someone checks on the first working day of the month before they will sign anything off.

Show me all purchase orders created today

14 purchase orders created today, across three company codes, totalling MYR 486,200.

POVendorCo. codeNet valueCreated by
4500018842Sime Industrial Supply1000MYR 128,400SITI.R
4500018843Northgate Engineering1000MYR 96,750SITI.R
4500018844Delta Valve & Fitting2000MYR 61,300A.KUMAR
4500018845Perdana Logistics3000MYR 44,900A.KUMAR

Showing four of fourteen. Three were raised against a vendor with no active contract — worth a look before they go for approval.

These open FI documents — predict which ones are likely to be paid late

Scored 312 open items against the payment behaviour of everything cleared in the last 18 months. Forty-one carry a high risk of running past their due date.

DocumentVendorDueRiskWhy
1900004471Northgate Engineeringin 6 daysHighLast six invoices cleared 12 days late on average
1900004488Delta Valve & Fittingin 9 daysHighBlocked for price variance, unresolved 11 days
1900004502Perdana Logisticsin 14 daysMediumGoods receipt posted, invoice not yet matched
1900004510Sime Industrial Supplyin 21 daysLowConsistently cleared early

This is a pattern drawn from your own cleared history, not a rule — treat it as the queue to work first, not a verdict on any one invoice.

Check every system — any dumps today?

Three systems checked. Two dumps in Production, none in QAS, seven in Dev.

SystemDumpsMost frequent
Production2CX_SY_ZERODIVIDE in a nightly job
QAS0
Dev7CX_SY_OPEN_SQL_DB — all from one developer's test run

The two in Production are the ones that matter: both came from the same scheduled job, and it failed silently — the job finished green because the dump was caught and swallowed.

Which custom programs exist in Dev but were never transported to Production?

Nine custom programs sit in Dev with no counterpart in Production. Four were changed in the last 90 days, so they are still live work; the rest have not moved in over a year.

ProgramDevQASProdLast changed
ZFI_REBATE_CALC11 days ago
ZMM_PO_UPLOAD_V22 months ago
ZRPT_LEGACY_0013 years ago
ZSD_QUOTE_FIX2 years ago

Showing four of nine. The three-year-old entries are the interesting ones — code that was built, never shipped, and is still being carried.

Is ZRPT_LEGACY_001 still used anywhere? Can we decommission it?
✓ Safe to retire
Callers
None anywhere in the landscape
Last run
Never — not present in Production
Transports
No movement in 3 years
Owner
Left the organisation
✕ Check before you delete
Batch jobs
A scheduled job would not appear in where-used
Dynamic calls
Callers built at runtime cannot be traced statically

Nothing references it, nothing runs it, and it never reached Production — so the recommendation is to retire it. The two checks on the right are the ones a where-used list genuinely cannot answer, and they are worth five minutes before anyone deletes anything.

Run ATC on package ZFI_REPORTS and show me what blocks a cloud move

ATC finished across 34 objects. Findings by priority:

PriorityFindingsWhat they are
P1 — critical7Statements not permitted in ABAP Cloud
P2 — high23Direct access to tables that are no longer released
P3 — medium61Naming, performance and obsolete syntax

Only the seven P1 findings actually block the move. The 61 P3s can wait — telling those apart is usually the difference between a three-week remediation and a three-month one.

Export that spec as a Word document

Written up per object — what is wrong, the released replacement, and an effort estimate — with the seven P1 findings first.

DOCRemediation_Spec_ZFI_REPORTS.docx14 pages · 34 objects · ready to send

Say the word and the same content comes out as a deck for the steering committee.

📎 🎙
☰ General ⌄
↵ to send · ⇧↵ for newline
Eight questions — understand, predict, decide, deliver.

That is one thread. It answers a great many more.

What people actually ask it.

Understanding code

  • "Explain what this program does in plain English"
  • "Which database tables does it read and write?"
  • "Who calls this function module? Show the where-used list"
  • "What objects are inside this package?"

Live data

  • "Show me all purchase orders created today"
  • "List the top 10 vendors by number of open invoices"
  • "GR/IR clearing accounts with open items older than 90 days"
  • "How many sales orders this month, per company code?"

Across the landscape

  • "Check every system — any dumps today?"
  • "Which custom programs exist in Dev but were never transported to Production?"
  • "How many custom programs across Dev, QAS and Production, side by side?"
  • "Which transports were released this week?"

Retiring what costs you

  • "Is this program still used anywhere? Can we decommission it?"
  • "When was it last executed in Production?"
  • "Give me the decommission recommendation"
  • "Find all custom Fiori apps deployed in this system"

Your own documents

  • "What did the blueprint say about this interface?"
  • "Find the functional spec for this program"
  • "Does this change contradict what we agreed at design?"
  • "Summarise the open decisions from the last workshop"

Things you can hand over

  • "Run ATC and generate a remediation functional spec"
  • "Export that spec as a Word document"
  • "Write the technical spec a developer can build from"
  • "Export all open POs from Production to Excel"
  • "Chart the ATC findings by priority for this package"
How it is wired

Three parts, one boundary.

Your people, ireya running inside SAP BTP, and the systems you already own. Everything inside the dashed line is your landscape — the question, the data and the answer stay in it.

Your people

A chat box

Opened in a browser with the company sign-on. Questions in plain language — nothing new to learn.

Your landscape
on SAP BTP

The chat and the orchestration

Holds the conversation, works out which systems to read, and records what was accessed.

SAP AI Core

Where the model runs — the commodity part, called from inside your own subaccount.

Your systems

SAP Cloud Connector

The controlled door in. Only the systems and clients you choose to open, under your own access rules.

S/4HANA or ECC

Live ABAP code, SAP objects and business data — Dev, QAS and Production, from the one chat.

No public AI endpoint appears anywhere on this diagram — which is the whole point of building it inside.

From dev tool to platform

Proven with SAP dev.
Built to reach every team.

The same pattern lets any team ask questions against their own systems, SAP or not.

— the central AI chat, connected to every system you run

Developers

live ABAP & SAP objects, ECC or S/4HANA

Finance

SAP + reporting tools

Operations

plant & ops systems

Any team

their own products

Developers are running now. The rest is the same platform, pointed elsewhere.

What management will ask

The likely questions — answered.

"Why not just buy Copilot or SAP Joule?"

Neither one sits above your systems. Copilot is grounded in Microsoft 365 — mail, files, Teams — and reaches SAP only through a connector or the Joule interoperability, so it inherits Joule's boundary. Joule lives inside a single system: one Joule per system, per client, with nothing above them. ireya is the layer that is missing: one chat across every system and client at once.

Ask it to…M365 CopilotJoule
Serve every system and every client from one placeone Joule
per system
Answer a single question across Dev, QAS and Production
Work against ECC, not only S/4HANA
Produce a functional spec as a documentfrom Microsoft
content only
Produce a technical spec a developer can build from
Reach non-SAP systems in the same conversationMicrosoft
estate only

Copilot is strong across the Microsoft estate, and Joule is capable inside the SAP cloud a client has already bought. Neither follows you back to ECC, and neither will hand your consultants a deliverable built from your own ABAP.

"We don't have BTP or SAP AI Core."

Then you do not need to buy them to start. There are two ways to run it, and both work today.

Run it…What it takesWhere the data sits
On your own BTPA BTP subaccount and an AI Core instance you already holdNever leaves your tenant
On oursNothing to buy — we create the subaccount and run BTP and AI Core for you; you pay for what you useOur tenant, isolated per client

Procurement is usually the longest pole in the tent, so the second option exists to skip it: we stand up the subaccount, connect it, and hand back a working chat. The choice is really about where the data sits — and moving to their own tenant later is a configuration change, not a rebuild.

"Is connecting AI to production SAP safe?"

It runs inside your own BTP landscape via Cloud Connector, with controlled access. Data stays in SAP AI Core.

"Isn't this just a developer tool?"

Dev is where it started, not where it stopped. The same foundation is being pointed at new problems and released as applications in their own right.

For delivery partners

What your firm gets.

ireya does not replace your engagement — it removes the unbillable ends: discovery at the start, write-up at the finish. What is left is the judgement your people are paid for.

Onboarding

Week one on a new client, not week four

The weeks after winning a client are discovery nobody wants to bill for. Connect their system and the estate answers for itself from day one — your consultants arrive knowing the landscape instead of spending a month learning it.

Margin

The grind goes, the engagement stays

Extraction and spreadsheets are what no client wants to pay for. Removing that work doesn't shrink the engagement — it moves the days into analysis they can see the value of.

Deliverables

The paperwork writes itself

Blueprints, object inventories, remediation specs — the documents an engagement is contracted to produce come out in Word and Excel as the work happens, not in the fortnight after it.

Repeatable

The next client starts where the last one finished

The same platform points at the next landscape. Assessment stops being bespoke each time and becomes something your firm runs the same way twice — a practice rather than a project.

Who is behind it

Built by SAP developers with twenty years in the landscape — every capability started as something that cost them a week of their own. Built against a live S/4HANA system, not a sandbox, because the awkward parts only show up when it is real.

Commercial terms are open by design: whether the software sits inside your engagement or beside it is a conversation, not a price list.

Why the name

ireya — a short word, deliberately empty.

It is a made word. It does not describe SAP, it does not describe chat, and it does not describe whatever the platform happens to do this quarter — which is the point. A name that describes today's product has to be explained away the first time the product grows past it.

Ownable

Five letters, one obvious pronunciation, and nothing else in the enterprise software market already answering to it.

Unbounded

Nothing in the word ties it to developers, to SAP, or to a single system — so nothing has to be renamed when it reaches the next team.

It is more than a chatbot — an intelligent companion that helps people:

Ask naturally Analyze intelligently Solve confidently Act quickly

ireya stands for clarity, intelligence and trusted guidance in every conversation.

The next step

See it run against a real system.

One chat across every system and client Connects to ECC or S/4HANA, live No BTP or AI Core? Run it on ours Data stays inside SAP BTP & AI Core No more pasting company data into ChatGPT

The only AI chat wired into your live SAP landscape, ECC or S/4HANA.

Book a live demo →

Opens WhatsApp. Thirty minutes on a live landscape answers more than any document can.