The line between a request and a ledger entry
An admin request system should own intentions and approvals: someone needs something, someone agreed, admin arranged it. The accounting system should own financial facts: a bill was received, a payment went out, an entry hit the ledger. If you run both, draw the boundary at the moment a commitment becomes a supplier document, and give each team clear ownership on its own side.
Companies blur that line in two directions. Some push finance coding into every admin request, so a pantry restock needs a general ledger account before anyone can approve it. Others let admin keep payment status in spreadsheets, so there are two versions of whether a supplier has been paid. Both waste time, and the second one causes disputes.
What lives on each side of the boundary
A practical test is to ask which team would be blamed if the record were wrong. That team should own it, and the other side should read it rather than retype it.
- Admin side: the internal request, who raised it, the business reason and the approver
- Admin side: quotations gathered, supplier chosen, delivery or completion confirmation
- Admin side: bookings for rooms, vehicles and shared facilities, which rarely touch the ledger
- Admin side: the status that tells the requester whether their item is ordered, delayed or delivered
- Finance side: supplier bills, credit notes and the tax treatment of each
- Finance side: payment runs, bank reconciliation and the supplier ledger balance
- Finance side: cost allocation, accruals and the reports management reads
- Shared reference: a request number that appears on the bill so either side can trace the other
Grey areas that need an explicit owner
Petty cash causes the most argument. Admin handles the float and the receipts; finance owns the balance and the replenishment entry. Decide that admin records each disbursement against a request, and finance only posts the replenishment total with the request list attached.
Recurring contracts are the second grey area. Cleaning, security and maintenance services are arranged once by admin and then billed monthly for years. Admin owns the contract and its renewal date; finance owns the recurring bill and its expected amount. When the two disagree, admin goes back to the supplier, not finance.
Supplier master data is the third. If admin adds suppliers freely and finance adds them again for payment, you end up with three spellings of the same vendor and bank details nobody has verified. Pick one team to create and verify suppliers, and let the other request additions through it.
Whichever split you choose, publish it as a one-page ownership note and attach it to both teams' procedures.
Signs you need both systems rather than one
A small company can live with requests by email and a single accounting package. The case for a separate admin request system grows when requests come from several departments or sites, when approvals need an audit trail, or when admin spends its week chasing status on purchases that finance already shows as paid.
Another signal is a month-end close that keeps stalling on admin purchases. If finance spends the start of every month asking who ordered what and why, the request information exists somewhere but not in a form finance can read. A request system fixes that by making the reason and approver part of the record from the start.
The case weakens if most spending is on a handful of fixed suppliers. In that situation a tidy approval step inside your existing accounting routine may be enough, and adding a second system creates more boundaries than it removes.
Which system to put in place first
When both are needed, put the accounting side in order first. Finance needs a clean supplier list, consistent cost centres and a reliable close before admin requests can point at anything meaningful. A request system that references cost codes finance is about to change will be rebuilt within months.
Next, introduce the admin request system for one category, such as office supplies or facilities repairs, with the shared request reference printed on purchase orders. Widen to more categories once finance confirms bills are arriving with that reference attached.
Prepare requesters before switching each category over. The usual failure is managers who keep sending requests by message because it worked before. A short note from the department head saying requests outside the system will not be processed does more than any training slide.
Fasttrade typically sets this up as one programme: BukuCloud for invoicing, bills, supplier payments and reports, followed by BukuAdmin for internal requests, documents and follow-up. Any data exchange between them is scoped with you at the start, not promised as a default.
Frequently asked questions
Can the accounting system handle internal requests on its own?
Some accounting packages offer purchase requisitions, and for companies with few requesters that can be enough. They tend to struggle with non-financial requests such as room bookings, document requests or repair follow-ups. If admin handles a wide mix of requests, a dedicated request system usually fits better, with finance kept as the owner of anything that becomes a bill.
Who should create new suppliers?
One team, and it should be written down. Finance is often the better owner because it verifies bank details and tax registration before the first payment. Admin can request a new supplier with the quotation and contact details attached, and finance completes the record. This stops duplicate vendors and reduces the risk of paying into an unverified account.
Do both systems need the same cost centres?
The admin request system only needs enough coding to route approvals and give finance a starting point, often the department or project. Finance keeps the full chart of accounts. If the request side carries the same cost centre list, make finance the owner of that list and update the admin side whenever it changes.
Next step
Explore BukuAdmin or tell Fasttrade what your team needs.
These articles explain enterprise process design. Product availability and detailed scope are confirmed in conversation.