Solutions · Finance

Maplith for finance

Finance closes the books from what other systems hand it: the quote from sales, the refund from the shop, the payment from the bank. Where two of them disagree, the ledger still balances — and the error sits in the space between. Your agent can find it — if it knows where each figure lives, how far to trust each join and whether it may act. Maplith gives it exactly that; your agent acts in your systems with your credentials.

LinguaNord ApS is a fictional translation agency built as our first test company: the company, its people, its customers and its translators are all invented, and nothing in the data comes from any customer. Fjeldrev Outdoor ApS is a fictional web shop built as a test company: the company, its people and its customers are all invented, and nothing in the data comes from any customer.

The workflowsfigures from the worked examples
Invoices that never matched the quotes
6 of 18 invoices never matched their quotes
Invoices sent with no payment received
5 of 18 invoices sent with no payment received
Refunds paid, never booked
4 refunds with no credit note · DKK 3,396
LinguaNord ApS · Fjeldrev Outdoor ApS
Where finance’s figures come fromLedgerProject systemShopBankKeys typed as free text
Between the systems

Where it goes wrong

Recurring problems between the ledger and the systems that feed it. Each was raised by a scan of a worked example’s exports.
01

Invoices keyed by hand

The invoice is typed from the quote, not generated from it, and no invoice carries its project — so an amount that drifts from the quote shows up nowhere.
LinguaNord ApS · raised by a scan of its exports
02

Refunds paid, never booked

The shop pays the refund; the credit note waits for a batch that does not come.
Fjeldrev Outdoor ApS · raised by a scan of its exports
03

Foreign currency booked at face value

In the worked example three orders paid in euro were booked in the ledger as the same number of kroner. A scan raised it as a finding, with the orders, the postings and the meeting where it was put off.
Fjeldrev Outdoor ApS · raised by a scan of its exports
Workflow 01

Invoices that never matched the quotes

Invoices are typed by hand from the quote, and some amounts drift from it.
Without Maplith
  • Compare the ledger’s invoices with the project system’s quotes, by hand.
  • Guess which quote an invoice belongs to: no invoice carries its project.
  • Hear about a mismatch when the customer writes.
With Maplith
  • A finding with the invoices and quotes it rests on.
  • The context in one call, with the join’s caveat.
  • A decision on a declared operation, by the key’s policy.
  • A record the next agent sees.
  1. FindingsInvoices whose amounts drift from their quotes, with the rows and the meeting it rests on and a recommendation.list_findings
  2. SignalsWhen a person approves a finding’s fix, a fix_approved signal.list_signals
  3. Task contextThe invoice and the project, the path between them and how well it holds, what was done last time.get_task_context
  4. The mapThe join from project to invoice is weak: no invoice carries its project, so the match is read with its caveat.get_object
  5. The action gateAn operation the business declared, such as a task for whoever invoices, decided by the key’s policy.request_action
  6. Record and valueWhat was done, so the next agent’s context shows it.record_action

Worked example: LinguaNord ApS

The full workflow, step by step

Without Maplith

The invoice is typed into the ledger from the quote, not generated from the project system, so the amounts drift. In the worked example no invoice carries its project, so nothing in either system shows which invoice belongs to which quote; the finance meeting names three mismatches in May, and the exports hold more. An agent without a map has to pull both exports, guess the match by customer name and amount, and start again next month.

With Maplith

  1. Findings

    A scan of the exports raises it as a finding: the invoices and quotes it compared, the meeting where the mismatch came up, and a recommendation. list_findings returns it.

  2. Signals

    When a person approves the suggested fix of a finding, list_signals returns a fix_approved signal and get_task_context gives the finding and its fix, so an agent polls for its work instead of re-reading the map.

  3. Task context

    get_task_context returns the objects it concerns, the join path between them with how well it holds, the open findings on them and what was done the last time.

  4. The map

    The map marks the join from project to invoice as weak: the invoice’s project field is empty in every row, so the agent treats a match as the caveat says rather than as fact.

  5. The action gate

    request_action for an operation the business declared — for example, opening a task for whoever sends the invoices — decided by the key’s policy.

  6. Record and value

    record_action writes what was done, so the next task context on the same thing shows it.

Workflow 02

Invoices sent with no payment received

Some invoices are still open, and the reminder has to find the right person in another system.
Without Maplith
  • Decide what counts as late, with nothing to compare against.
  • Find the customer’s contact in another system, under a name spelled differently.
  • Do it again every week.
With Maplith
  • The process: sent, then paid, and the usual time between.
  • A route to the customer’s contact, with the join’s caveat.
  • An answer from ask, citing what it rests on.
  • A decision on a reminder, by the key’s policy.
  1. ProcessesThe invoice’s happy path — sent, then payment received — the usual time between, and the invoices that stop after sent.get_process
  2. RouteFrom the invoice to the customer’s contact: which system, by which key, and that the first hop is weak.route
  3. AskWhere the contact for an invoice lives and what not to rely on, answered from the map, never from rows.ask
  4. The action gateA reminder to the customer, if the business declared one: allowed, pending a person, or denied.request_action
  5. Record and valueWhat was done, so the next agent’s context shows it.record_action

Worked example: LinguaNord ApS

The full workflow, step by step

Without Maplith

The ledger knows which invoices are open; it does not know who to remind. The customer’s contact sits in another system, under a name the ledger spells its own way. In the worked example some invoices have a sent date and no payment after it. An agent without a map has to decide what counts as late with nothing to compare against, then find the contact by guessing how the ledger’s customer name matches the others.

With Maplith

  1. Processes

    get_process for the invoice returns its happy path from the dates in the exports — sent, then payment received — with the median time between the steps, and every variant that deviates, including the invoices that stop after sent. An open invoice is late against the business’s own median, not a guess.

  2. Route

    route from the invoice to the customer’s contact says which system holds each and by which key — and that the hop from invoice to customer is weak, because the ledger names the customer in free text. The agent reads the contact in that system with its own credentials.

  3. Ask

    ask: “where do I find the contact for an invoice’s customer, and what should I not rely on?” — answered from the map with the objects and joins it rests on, never from rows.

  4. The action gate

    request_action to send a reminder, if the business declared that operation: allowed, pending a person, or denied, by the key’s policy.

  5. Record and value

    record_action writes what was sent, so the next task context on the same thing shows it.

Workflow 03

Refunds paid, never booked

The shop pays a refund; the ledger never gets the credit note.
Without Maplith
  • List the refunds in the shop and the credit notes in the ledger.
  • Match them by an order number typed into free text.
  • Find the gap before the VAT return, not after.
With Maplith
  • A finding naming the refunds with no credit note, and the procedure they break.
  • The context in one call: the objects and the path between them.
  • A decision on booking them, with a person’s approval if the business wants one.
  • A record of what was booked.
  1. FindingsThe refunds with no credit note, the procedure they break, and a recommendation.list_findings
  2. SignalsWhen a person approves a finding’s fix, a fix_approved signal.list_signals
  3. Task contextThe refunds and the ledger, the path between them and what was done last time.get_task_context
  4. The action gateBooking a credit note: a person approves each one, if the business sets it so.request_action
  5. Record and valueWhat was done, so the next agent’s context shows it.record_action

Worked example: Fjeldrev Outdoor ApS

The full workflow, step by step

Without Maplith

The procedure says the credit note is booked the same week as the refund. In the worked example the bookkeeper books refunds in batches when there is time, and four refunds paid in the shop — DKK 3,396 in all — have no credit note in the ledger, though the ledger runs weeks past the last of them. The shop and the ledger each look complete on their own.

With Maplith

  1. Findings

    A scan of the exports raises it as a finding: the refunds with no credit note, the procedure step they break, the chat where the batching is admitted, and a recommendation.

  2. Signals

    When a person approves the suggested fix of a finding, list_signals returns a fix_approved signal and get_task_context gives the finding and its fix, so an agent polls for its work instead of re-reading the map.

  3. Task context

    get_task_context returns the objects it concerns, the join path between them with how well it holds, and what was done the last time.

  4. The action gate

    request_action to book a credit note, if the business declared that operation: the business decides per key whether a person approves each one. Maplith never books it; the agent does, in the ledger, with the business’s own credentials.

  5. Record and value

    record_action writes what was booked, so the next task context on the same thing shows it.

The pieces

What your agent calls

Where each thing lives and how the systems join, with the rate Maplith measured for every join it could test.
get_object
Where the systems disagree, raised by a scan of the exports — each with the evidence it rests on and a recommendation.
list_findings
How the work actually flows, from the dates in the exports: the happy path, the time between steps, and every variant that deviates.
get_process
What needs doing, as typed events to poll instead of re-reading the map.
list_signals
A single call with everything a signal needs, including the playbooks and what the key may do.
get_task_context

Ask

live
One question in plain language, answered from the map with citations — never from rows.
ask

Route

live
The shortest verified join path from a start object to a target: which system, which key, how much to trust each hop.
route
Allowed, pending a person, or denied — before the agent acts, with a grant good once.
request_action
What was done, so the next judging does not raise it as though nobody had looked — and counted in “What you got”.
record_action

Map your exports. The first map is free.

Your systems stay the source of truth; your agent acts in them with your credentials.

Markdown version · Worked examples · Docs · llms.txt