Enterprise

Your systems stay. Your controls stay. The work still gets done.

Khotan builds procurement applications on the systems you already run. Every deployment starts with a defined access boundary, named approval gates, and a record of what the software did.

Book a working sessionSecurity documentation

The six questions your security and architecture teams ask first

We connect the sources one process needs. Nothing beyond them.

A first application does not require access to your estate. It requires the smallest set of sources the process depends on, agreed in writing before anything is connected.

Read
Only the objects the workflow touches. For invoice processing that is invoices, purchase orders, goods receipts, supplier records, and the mailbox they arrive in.
Written back
Only the fields and records named in the scope, into the system that owns them, after a person has approved the result.
Left alone
Everything else. Your ERP, contract system, and purchasing tools stay authoritative and unchanged.

Access boundary diagram: source systems on the left, the scoped set Khotan connects in the middle, writeback targets on the right

Where it runs is your decision, not our default.

Deployment is settled during the access review, before a line of the application is written.

  • Connected in place

    Khotan reads from your systems and writes results back to them. The authoritative record never moves.

    Default for a first application.

  • Your cloud account

    Unverified

    The application and the data it depends on run inside infrastructure your team owns and monitors.

    Available on request.

  • Khotan-hosted, your region

    Unverified

    A managed environment pinned to a region you choose, with the source systems reached over private connectivity.

    Regions to be confirmed.

Permission is a property of the application, not of the company.

Each application carries its own access model. A category buyer working invoice exceptions sees the invoices, orders, and suppliers in their categories. They do not inherit the contract terms or the spend history that a different application exposes to a different role.

Where your source systems already restrict a record, that restriction travels with it. Khotan does not widen access as a side effect of connecting a system.

Identity and provisioning

Confirm support
  • Single sign-on through your identity provider
  • Directory-driven provisioning and deprovisioning
  • Role scoping per application and per dataset

Specific protocol support is confirmed against your identity stack during the access review.

Khotan prepares the decision. A person makes it.

Every action with a commercial or external consequence stops at a named human. This is the control model, written out for the workflows we build most often.

  • ActionInvoice matched to a purchase order and goods receipt
    What Khotan preparesThe match, the mismatch, and the documents behind both
    Who approvesAccounts payable approver
    Where the result landsERP
  • ActionSupplier chased on a slipping delivery date
    What Khotan preparesA drafted message with the order, the contract term, and the history
    Who approvesThe buyer who owns the category
    Where the result landsOrder record and message log
  • ActionContractual credit calculated against a missed service level
    What Khotan preparesThe calculation, the clause it rests on, and the evidence
    Who approvesContract owner
    Where the result landsContract system
  • ActionPurchase request checked against policy
    What Khotan preparesThe policy result and the approval route it implies
    Who approvesThe approver the policy names
    Where the result landsPurchasing system

The evidence, the approval, the action, and the writeback sit in one trace.

An auditor asking why a credit was raised should not need three systems and a conversation. The application records what it read, which rule fired, who approved, what it did, and where the result went.

Audit trace: a single procurement action expanded from source documents through rule, approval, and ERP writeback

One team owns the path from your source systems to a working application.

You are not coordinating a data vendor, an integrator, and an application developer. The engineer who scoped the process is the engineer who runs it afterwards.

  1. Scope

    One process, the systems it touches, and the measure that decides whether it worked. Agreed before any access is granted.

  2. Access review

    Your security and architecture teams review the source list, the permissions requested, and the writeback boundary. They sign that list, not a platform.

  3. Build

    A Khotan engineer builds against your data, your rules, and your exceptions. The awkward cases are requirements, not edge cases to handle later.

  4. Acceptance

    You test the application against the measure you set. That result decides whether it enters the operation.

  5. Run

    The same team keeps it running and takes the next process from the connections and rules this one created.

What we can hand your reviewers today.

We would rather tell you what is not finished than let you discover it in a questionnaire. Current status is below.

Request the security pack
  • SOC 2 Type II reportNot yet attested
  • Penetration test summaryScheduled
  • Data processing agreementAvailable on request
  • Subprocessor listAvailable on request
  • Architecture and access review packAvailable on request

Questions that come up in procurement

Bring the security review to the first call.

Come with one process that costs your team the most repeated work. We will map the systems behind it, the access it needs, and where the approval boundary sits, in the same session.

Book a working sessionAbout Khotan