One record everything works from.
Accounting, sales and service see the same debtor, and an agent reads the same data under the same permissions. What a view shows is not a snapshot: a view is a stored query, and it is recomputed every time it is opened.
Search or jump …
⌘KViews
Customers
Open documents
Clarifications
⏎ opens the record
Opened
Becker Industries SE
- Customer Number
- 48213
- Customer Group
- Key Accounts
- Credit Control Area
- DE01
- Balance
- €1,204,000
- Dunning Stop
- Inactive
- Risk Manager
- J. Alvarez
A hit opens the object itself, not a list it happens to be alone in.
Jump menu
Reachable from here
- Open documents 41
- Reminders 6
- Promises to pay 2
- Customer letters 9
- Clarifications 1
Navigating is not an action — it changes nothing.
All documents · Company code DE01
Totals per currency
EUR €48,200,000
CHF CHF 1,284,000
What is stored is the query. The figures happen on opening.
A different account
Customer group Key Accounts
This person has no data access to that customer group. Nothing comes back — not even when an agent asks.
Aging
Configured aging ladder
-
due today 18%
-
1–14 days 34%
-
15–30 days 27%
-
over 30 days 21%
The same classes as the due-date report. Without that configuration the block stays empty.
Connected once, checked from then on.
Your ERP or CRM delivers debtors, documents and payments over the REST API, the batch interface or as a file. The import runs in seconds, webhooks keep the record in sync, and integrity is checked around the clock — not first thing when someone opens a report.
How the connection is built is the Integration Layer's subject. This page starts one step later: at the record that comes out of it, and at what everyone involved sees in it.
- Source
- ERP, CRM or file — REST API, batch interface or file handover.
- Import
- Debtors, documents, payments and master data land in the record in seconds.
- Checks
- Integrity checks run around the clock, automatically, not on request.
- One record
- From here on every surface and every agent works on the same data.
Everything hangs off the debtor, and that is more than a dozen things.
It is not only documents that hang off a customer. Limits, securities, risk classes, credit reports, insurance cover, balance-sheet analyses, clarifications, letters and their history all sit in the same record under the same permissions — there is no second place where part of it is maintained separately.
- Customers
- Master data, balance, reminder level, customer group.
Receivables management
- Open documents
- Amount, due date, currency, company code.
- Reminders
- Level, reminder date, open volume, dunning stop.
- Promises to pay
- Date, amount, whether it was kept.
- Customer letters
- Occasion, recipient, delivery channel.
- Clarifications
- Reason, owner, effect on the reminder.
Credit Management · only where the module is booked
- Credit limits
- Amount, utilisation, score and risk class, origin.
- Limit suggestions
- Active and new limit, credit policy, validation, approvals.
- Credit reports
- Score, provider, report date, recommended limit.
- Insurance cover
- Security type, coverage, status, term.
- Securities
- Type, status, start and expiry.
- Risk alerts
- Type, priority, status, credit policy.
The routes between the objects are part of the explanation: from a customer to its documents, from a document back to its customer. Navigating is never an action — a change of view changes nothing.
Of those, object types for an agent
Customers, open documents, reminders, promises to pay, customer letters and clarifications are object types of their own, and with Credit Management booked so are credit limits, limit suggestions, credit reports, insurance cover, securities and risk alerts. An agent can list, filter, total and open them, always with the read permissions of the role; it writes an analysis for customers. Everything else is there in the interface, in the reports and over the API.
Same record, same customer
- Risk classes
- Credit policies
- Balance-sheet analyses
- Payments & clearing
- Deductions
- Sales orders
- Addresses & contacts
- Customer groups
- Company codes
- Dunning stops
- Comments
- Documents & files
A view is a query, never a snapshot.
What is stored is the question, not the answer. That is why a view shows the current state the second time it is opened, and why no analysis can work with figures nobody can find again.
- Recomputed on opening
- Reopening, reloading and "show more" all take the same path. Stale rows cannot occur.
- Exact totals, per currency
- Totals are counted, not estimated, and reported per currency — a total across currencies would be wrong.
- Refining creates a new query
- A query never changes after it is created. Refining produces a second one; the first stays readable.
Type, don't search — two places, two questions.
Two input fields that differ on purpose: one asks "where to?", the other "what with what is loaded here?". Both run the paths the mouse already takes; neither is a second execution path.
Command palette
12 reminders selected
- Target
- Selection (12) checked
- Actions
- Send reminder
- Set dunning stop customer, document
- AI
- Analyse template optional
⌘K jumps, ⌘⇧K acts
Jumps to views, customers, documents and clarifications, and to everything this session has produced. A leading type word narrows the search ("customer becker"), and picking a record opens it — not a list with one row in it.
Slash commands
- /filter set a filter of the loaded view
- /sortieren sort by a column
- /spalten switch the column set
- /speichern keep the view as a list
- /senden send the checked reminders
No language model, no cost
Filter, sort, choose columns, send what is checked — straight from the composer, without a language model and without cost. Anything ambiguous stays a question rather than becoming a guess.
Both paths know the permissions of the person acting. Opening a view without the right to see it returns nothing — including when an agent asks.
The same data for accounting, sales and service.
Clarification management, dunning and credit decisions do not work on copies but on the same debtor record. A note from sales is visible in dunning, a clarification holds its reminder back, and nobody has to ask which list is the newer one.
Accounting
Open documents, incoming payments, reminder levels and due dates in the structure you configured.
Sales
Balance, limit and open clarifications on the customer — without a detour through accounting.
Service
Clarifications with their reason, their owner and their effect on the running reminder.
Permissions apply to people and agents alike
Access follows the existing roles and data scopes and is closed when in doubt. An analysis never sees more than the person it runs for, and an agent does not read a customer group that person cannot open.
Your aging ladder, in your own words.
The aging classes come from your configuration — the same boundaries and the same labels as your due-date report. An analysis adopts them instead of giving itself its own.
With no ladder configured, the aging breakdown stays empty. No 30/60/90 days are assumed and no cut-off is guessed — a class you do not have is not reported.
Example of a configured ladder
-
due today 18%
-
1–14 days 34%
-
15–30 days 27%
-
over 30 days 21%
What explicitly does not happen here.
The shortest test of a data foundation is the list of what it does not do. These points are built this way deliberately, and the next model does not change them.
- There is no second store beside the record — not even a copy for reporting.
- No view stores rows. The query is what is stored; the figures are computed on opening.
- No list without an object type. An agent only queries what is declared as a type — with its filters, columns and permissions.
- No figure comes from the language model. Counting, totalling and classifying is the database's job.
- No totals across currencies. Sums stay separated per currency.
- No invented aging. Without a configured ladder the breakdown is left out.
- No read access around the roles. Without the permission the result stays empty.
What finance leaders ask about this first.
As current as the view you open yourself — it is the same path. The import runs in seconds and webhooks keep the record in sync; a query is computed when it is opened rather than answered from an intermediate state. Where only record ids are given, the query goes straight to the database, because a search index always lags behind a write.
No. Every query checks the acting person's read permissions and returns nothing when in doubt. A person without a company assignment gets an empty result rather than a company-wide one. So an agent cannot surface anything that would be hidden in the familiar interface.
Yes, for a structural reason: totals are aggregated rather than estimated, with an exact hit count instead of an approximation, and reported per currency. A total across currencies would be wrong, so it does not exist. The figures are in the result before a model writes a sentence about them.
Yes. Every query is stored as an immutable descriptor and its reuse is counted; refining creates a second query instead of overwriting the first. So you can read back which question was asked — the answer to it is today's state, not the one from back then.
Because a type is more than a name: it brings filters, columns, totals, permissions and the list of permitted actions with it. A new type is therefore development work rather than a setting — and that is exactly what makes the boundary verifiable. That is how credit limits, limit suggestions, credit reports, insurance cover, securities and risk alerts arrived with Credit Management. An agent does not even offer the types of a module you have not booked.
You are the ones who set them. An analysis adopts the classes and labels of your due-date report unchanged, so the same figure means the same thing in both tools. Without that configuration the aging breakdown is left out rather than computed against an assumed 30/60/90.