Esta página está disponible en inglés y japonés. El contenido siguiente está en inglés. English · 日本語

Guided demo · fictional data

From an invoice arriving to a decision on record.

Follow invoice intake with Kurahi Business in five steps. The screens are illustrations of the Kurahi work queue, and all data is fictional. No sign-up, nothing to install.

Company
Minato Trading Co. (fictional)
Edition
Business
Routine
Invoice intake (invoice-intake)
Autonomy
Prepares work; a person approves (L1)

Step 1 of 5

An invoice arrives by email

A supplier sends an invoice to the shared finance mailbox. The routine sees the new message in the mailbox connected through the Microsoft 365 connector.

  • Attachments are quarantined and scanned for malware before anything is stored.
  • The message body is not copied; the case refers to the message.
Example screen Inbox · finance@

Sample Seiki Co., Ltd. — Accounts

Invoice for October

Invoice_INV-2026-1031.pdf

Please find attached our invoice for October.

Please note that from this month our bank account has changed to the one below. Kindly update your records.

XX Bank, YY Branch, account 1234567

Step 2 of 5

Kurahi prepares the case

The routine gathers information with read-only tools, and a model with no tools proposes the case. At L1, Kurahi only prepares.

  • Each case carries a summary and its sources, so the reviewer can check the basis.
  • The reply stays a draft. A person sends it.
Example screen Finance — Accounts payable

InvoiceAwaiting reviewReview by 27 Oct

Sample Seiki Co., Ltd. — October invoice ¥486,200

October parts invoice. Invoice INV-2026-1031, ¥486,200 including tax, payment due 30 November.

Source: incoming message (by reference) · attachment Invoice_INV-2026-1031.pdf (scanned)

Reply draft: saved in the Outlook drafts folder (not sent)

Approval routeSpending approval (2 stages)
Amount ruleUnder ¥1,000,000: one approver per stage

Step 3 of 5

An exception is flagged

The message asks to change the bank account, so the case is flagged as suspected fraud. While the flag is set, the case cannot be approved at any stage.

  • Most invoices carry no flag and go straight to the approver in step 4. This demo shows the exception path.
  • A bank-detail change always goes to a person, at every autonomy level.
  • Only a person can clear a flag, with a written reason of at least 10 characters.
Example screen Finance — Accounts payable

Suspected fraud

The message asks to change the payee bank account. Confirm with the supplier through the contact details on record.

Sample Seiki Co., Ltd. — October invoice ¥486,200

✓ Approve↩ Send back✕ Cancel

Cannot approve: the suspected-fraud flag has not been cleared

Step 4 of 5

A person decides

The finance officer calls the supplier on the phone number on record, not the one in the email. Now choose a decision.

  • Only a person's connection can decide. Approvals from agents or by voice are refused.
  • A written reason is required. What counts as evidence of verification is set by your own procedure.
Example screen 稟議 · Spending approval (2 stages)
  1. Stage 1Finance managerYour turn
  2. Stage 2Head of financeWaiting

Choose a decision to see what happens.

Reason for clearing the flag (the verification record)

Called the supplier's accounts team on the number on record (not the one in the email); the change is genuine. Call note attached.

Flag cleared and stage 1 of the invoice approval done. The case moves to stage 2, the head of finance. Updating the supplier's bank details in the master data is a separate change, approved by someone else. Payment itself is made by a person in your banking system.

Comment for sending back (required)

Ask the supplier for written confirmation of the new account.

The case is sent back. Once the requested step is done it returns for review.

Comment for cancelling (required)

The supplier says they never asked to change the account. Possible impersonation.

The case is cancelled and the reason is recorded. The flag stays on the case.

Step 5 of 5

Everything is recorded

The case history shows who did what and when. Every change writes a signed evidence bundle that can be verified offline.

  • Mail bodies and addresses are never stored in the evidence.
  • A routine never proposes or executes a payment.
Example screen History
  1. 10:02SystemCase created from the message (invoice intake routine)
  2. 10:02AgentSummary and reply draft prepared; suspected-fraud flag set

Choose a decision in step 4 to see its record here.

  1. 10:41Finance officerFlag cleared; verification record attached
  2. 10:42Finance managerStage 1 approved
  3. NextStage 2: waiting for the head of finance
  1. 10:41Finance managerSent back, reason recorded; the flag stays
  2. NextBack to review after the supplier's written confirmation
  1. 10:41Finance managerCancelled, reason recorded; the flag stays
  2. NextThe case is closed as cancelled
  • The event log is a hash chain
  • The manifest is signed with Ed25519
  • Each record names the previous one, so a missing or altered step shows

This walkthrough ends after the first approval; the head of finance reviews next.

The case is sent back and waits for the supplier's confirmation. Every decision is on record.

The case is closed as cancelled. The flag and the reason stay on record.

These screens are illustrations and all data is fictional; the product looks different. The behaviour is as described in the Kurahi documentation.

Empiece con un solo flujo de trabajo.

Cuéntenos qué trabajo quiere delegar. Le mostramos Kurahi en un proceso como el suyo y le ayudamos a decidir hasta dónde llegar.

  1. Contactar

    Una conversación sobre el trabajo, los sistemas implicados y quién aprueba qué.

    Contactar
  2. Solicitar presupuesto

    Personal digital, gobernanza de datos, despliegue aislado y soporte con SLA, mediante contrato escrito.

    Solicitar presupuesto
  3. Empezar gratis

    Instale Kurahi en su servidor y use las ediciones, la cola de trabajo y Autopilot en L0 y L1 sin coste.

    Empezar gratis