Skip to content
Horulabs

Purchase requests that reach the right approver.

One request, one route, one record.

For operations, purchasing, and finance teams whose office-goods requests still start in chat and end with someone re-typing the approved list into the accounting system.

How a purchase request can run

6 steps

  1. RequestThe requester lists items, quantity and a needed date
  2. CheckThe first approver confirms the request
  3. PricePurchasing confirms price and unit
  4. ApproveCategory and value choose the rest of the route
  5. PostThe approved request becomes a requisitionAutomated
  6. TrackThe status follows the order as it movesAutomated

The next request follows the same rule

The shape of the flow, not a shipped client process. Your approval levels, item fields, and accounting system are set with your team.

Illustrative example

The request is simple. The route is not.

A team needs paper, a spare part, or a toner cartridge. Someone writes it in a chat, adds a photo of a catalogue page, and the quantity changes twice before anyone approves it.

The approval rule already exists, in a document or a spreadsheet: above a certain value, one or two more people sign. Applying it means forwarding a message and waiting for whoever is at their desk. A request can sit for a day, or be approved at the wrong level and corrected later. Not every company runs it this way, but the shape is common.

Then purchasing re-types the approved request into the accounting system. By the time the purchase order exists, the original request no longer shows what happened to it.

Your systems stay. The request gets a front door.

Horulabs fits the flow around the systems you already run. It does not replace your accounting system, and it does not ask finance to keep a second set of books.

Stays in your systems

  • Your accounting system

    Approved requests post into Accurate Online. Items, purchase orders, and master data still come from there.

  • Your approval rules

    The hierarchy of roles, categories, and value limits stays yours. We encode the rule you already apply.

  • Your records

    Requisitions, orders, and payments live in the accounting system. The request shows their status; it does not become a second ledger.

Built around it

  • One request form

    Itemised lines, quantity, unit, needed date, notes, and attachments in one place.

  • A visible route

    The next approver sees the request at their step. A request can be rejected or returned with a reason.

  • The post and the status

    The approved request is posted as a requisition, and its status follows the order as it moves.

The same job, running at Sekar Laut.

Sekar Purchasing handles requests for an internal procurement program at a food manufacturer in Sidoarjo. The case file covers the approval rule, the flow, and the posting to Accurate Online.

Start with one request flow.

The first task is this flow end to end: the form, the approval route, and the posting to the system you already use.

  • We map the request as it runs today, including the exceptions people handle quietly.
  • The flow is built and tested on real requests before the team uses it.
  • You get a handover for the team. A second flow or an integration is quoted separately.
Start a free consult on WhatsApp (opens in a new tab)

A short description is enough. No employee records or attachments.

The first conversation is free, with no commitment.

Questions before you start

Do we need a documented process?
No. We map the request with the people who run it, including the steps that only exist in chat.
Do we have to change our accounting system?
No. The flow posts into the system finance already uses. Replacing it is not part of the work.
What should we send first?
A short description of the flow, the roles that approve, and where the request is recorded today. Please do not send employee records or attachments.