It learns your rules
It reports on your basis, not its own
Give it the documents you have already written (reporting standards, close policy, pricing guidelines), and it works out which figures each one governs.
- A rule about order counts never lands on a revenue figure
- A governed answer says which document governed it
- The raw number is marked, and marked clearly
- Your documents stay in your tenant
Admin · knowledge scope
Upload the standards you already have and AnrilX works out which figures each one governs. Blueprint SD-RPT-047 defines how sales order value is reported here, and the right-hand column is the part worth checking, because a rule that could reach anything would be worth nothing.
Governs
- ZA_SalesOrder · TotalNetAmount
- ZA_SalesOrder · rejection handling
- reporting period basis
Never touches
- I_PurchaseOrderHistory · any field
- billing document values
- anything outside SD
Documents read
SD-RPT-047 Sales Order Reporting Basis §1, §5, §7
net order value · rejection handling · period basis
SD-PRC-009 Pricing and Discount Guidelines §6.1 – §6.4
which condition types count as a discount, via ZSDT_DISC_TYPE
FI-CLS-012 Month-End Close Procedure §3, §4
which postings a closed period includes, via ZFI_PERIOD_MAP
MM-PRC-021 Price Comparison Standard §2
effective unit cost, including freight conditions
SD-RPT-051 Regional Sales Reporting (draft) not mapped
escalated: “region” resolves two ways and the document does not say which
Your tables it resolves through
ZSDT_DISC_TYPE Condition types the blueprint treats as a discount
18 rows · read-only · maintained by the pricing team
ZSD_ORD_EXCL Order types excluded from revenue reporting
4 rows · free-of-charge and returns
ZFI_PERIOD_MAP Fiscal period to calendar month
your year starts in April, so “last quarter” is not a calendar quarter
ZMM_SUPP_GRP Supplier groupings used in spend reporting
present in no standard hierarchy
Source: Business Blueprint SD-RPT-047: Sales Order Reporting Basis · sections 1, 5 and 7
A rule about order counts is structurally unable to land on a currency figure. The scope is derived from the document, then shown, rather than configured by hand. Where a definition resolves through one of your own tables rather than a standard field, the table is named above and read at query time: a blueprint that says “discount means what is in ZSDT_DISC_TYPE” is applied by reading ZSDT_DISC_TYPE, not by copying its contents into a setting that then goes stale. A document that grounds onto nothing is listed unmapped and escalated; it is never applied approximately.
How it works
01
Scope is worked out when the document arrives
On upload, each document is read once to establish which figures it governs: which entity sets, and which kinds of measure. That judgement is made at ingest and stored, so applying it later is a single indexed lookup rather than a search on the hot path of every question.
02
A rule is bound to a kind of figure, not just a subject
A standard about order counts is structurally prevented from adjusting a currency figure. This is the failure worth engineering against: a wrong number that arrives with a citation attached looks checked, and is therefore trusted more than a wrong number with nothing behind it.
03
The unadjusted figure is marked, not hidden
Where a rule changes a number, the answer names the document, states the adjustment, and marks the raw figure as unadjusted. Somebody who needs the raw number can still see it; nobody can circulate it by accident.
04
It fails open, on purpose
If the knowledge store is unreachable, questions are answered the way they were answered before any document was uploaded. The alternative (refusing every figure in the product because a lookup failed) is worse than the problem it guards against.
The gap this closes
Most reported figures in a large organisation are not raw. There is a basis: an allowance that applies, a category that is excluded, a rounding convention, a rule about which version of a number may leave the building.
That basis is real, it is written down, and it lives in a document, not in the system computing the numbers. So compliance depends on whoever built the report having remembered it, and on everybody reading that report knowing which conventions it was built under.
Deciding scope once
When a document is uploaded, AnrilX reads it to work out what it governs: which entity sets its rules apply to, and which kinds of measure: a count, an amount, a list of rows.
Doing that work at upload rather than at question time matters for two reasons. It keeps the cost off the path of every question you ask, and it produces something a person can inspect. The scope of every document is visible, which is the only way to catch the two errors that are otherwise invisible from both ends: a tag so broad that every question about an entity gets routed through a rule that does not really apply, and a missing tag that leaves a rule quietly unenforced.
The mistake worth engineering against
A rule that lands on the wrong figure is more dangerous than no rule at all, because the answer arrives carrying a citation. It looks checked. A reader who would have questioned a bare number accepts one that names the standard it was computed under.
That is why a rule is bound to the kind of figure and not only its subject. A standard about order counts cannot reach a currency figure, not because the platform is instructed to be careful, but because the match requires both to agree.
Where it stops
What this capability will not do
Where this one stops, said here rather than discovered in a pilot.
-
A rule that has not been scoped yet is invisible to the fast path. The platform reports which documents are in that state rather than letting them sit unenforced.
-
Scope is derived automatically and can be wrong. Every document's scope is shown, because an over-broad tag and a missing one are both invisible from the outside.
-
This governs how figures are reported. It is not an approval workflow; that is a separate mechanism.
Questions people ask us
What kind of documents can I upload?
The ones you already have: reporting standards, close procedures, pricing and discount guidelines, order-to-cash blueprints. They do not need rewriting into a rules format; the platform reads them as written.
How do I know a rule was applied?
The answer says so and names the document. Where a figure was adjusted, the unadjusted value is shown alongside it and marked as not for circulation.
Do our documents leave our environment?
No. AnrilX is deployed on-premise inside your landscape. Your documents, your SAP data and your policy configuration stay there.
Next
Conversational SAP
Ask it the way you would ask a person
No query language, no entity names, no transaction codes. A question in plain English comes back as figures, with the SAP field and the period they were computed from printed underneath.
From answer to action
Nothing reaches SAP unapproved
When something must change, the exact change and the exact SAP call are put in front of a person first. Approve it and it runs. Reject it and the reason becomes a constraint for the rest of the conversation.
Live reporting
A report you can page, sort and keep
Tables that page, sort and filter inside SAP rather than over an extract. Save one, come back tomorrow, and it is reading today's data.
Bring the question your reports cannot answer
Thirty minutes against a live SAP system we provide: no access to yours, nothing to set up. If it cannot answer, you find that out in half an hour rather than three months into a pilot.