web.iti
ID

// systems · warehouse · multi-location & batch

A Custom Warehouse Inventory App for the scale a simple stock app can't hold

Multiple locations with transfers between them, batch and expiry tracking, stock counts with variance approval, carton-to-piece conversion. If you run one warehouse with one operator, an off-the-shelf app really is the better answer — and we'll say so plainly.

Free scoping call → (opens in new tab)See the cost breakdown

A custom warehouse inventory app is a stock system built around your own warehouse layout, units of measure, and goods handover flow — not an in-and-out template. It handles inter-location transfers, batches and expiry dates, serial numbers, stock counts with variance approval, and unit conversion from cartons down to pcs. An off-the-shelf Rp 2jt stock app and a custom Rp 20jt warehouse system are not two prices for the same product; they answer different questions at different scales. Full custom warehouse-system work starts at Rp 15jt, with the exact written quote set after a discovery session.

// modules we build

What ships with every warehouse system

  • ✓Tiered location master data — warehouse, zone, rack, bin — so stock has an address, not just a quantity
  • ✓Two-stage inter-warehouse transfers: goods sit in-transit until the receiving warehouse hits accept, so nothing ever goes missing in between
  • ✓Batch and expiry-date tracking with FEFO issuing, plus alerts as shelf life runs down
  • ✓Per-unit serial numbers for warranty items — a single unit can be traced from receipt through to return
  • ✓Consignment stock separated by owner, so one physical pile still makes clear who carries the value
  • ✓Scheduled stock counts and cycle counts alike, with variances that must clear approval before they touch the balance
  • ✓Tiered unit conversion — carton, dozen, pcs, kilogram — calculated by the system, not recalculated on someone's phone calculator
  • ✓A phone-based scanning app for warehouse staff: big screen, big buttons, usable standing up with one hand holding the goods
  • ✓Offline mode for receiving and picking: scans are stored on the phone when the internet drops, then synced with clearly defined conflict handling
  • ✓A full document flow — PO, delivery note, goods receipt, picking list, returns, and stock adjustments — numbered and sequential
  • ✓Integration with the POS and accounting you already run: Moka, Olsera, Pawoon, Accurate, Jurnal
  • ✓An audit trail on every stock movement: who, when, which document, from what value to what value, and it can't be deleted
  • ✓Stock-card reports per SKU per location, inventory ageing, dead stock, and a per-period recap of count variances, exported to Excel and PDF
  • ✓WhatsApp notifications for minimum stock, batches nearing expiry, and count variances awaiting approval

// when a stock app stops being enough

The scale thresholds where a simple app starts leaking

Picture a Saturday morning, count day, and the physical tally is 1.240 pcs off from the records. "There was probably a delivery yesterday that never got keyed in." Except the goods already went out the door — and the fault isn't the person, it's a tool with nowhere to record that event. A basic stock app answers one question: how much is left. A warehouse system answers a question shaped differently — which item, on which rack, which batch, whose it is, and who touched it last. As long as your warehouse is one location, one operator, one unit of measure, the first question really is enough, and buying the second is a waste. The threshold gets crossed when locations multiply and goods start moving between warehouses; when products have an expiry date so stock is no longer uniform; when one SKU is sold in cartons, pcs, and kilograms at once; when some of the goods on your racks actually belong to a supplier and only get paid for once they sell. At that point Excel and a stock app aren't short on features any more — both have lost the right shape of data. It's this difference in scale that sets the number in the proposal, not the length of the feature list.

// stock app vs warehouse system

Two different products that get compared on price

AspectOff-the-shelf stock appCustom warehouse system
Number of storage locationsOne warehouse, one quantity column. If you've got a shop and a back warehouse, the two often get recorded as a single number — and nobody knows where the goods actually are.Tiered locations down to rack or bin level. One SKU can hold different balances in five places at once, and each place has its own stock card.
Inter-warehouse transfersUsually handled as an issue in one place then a receipt in another, two separate transactions. If the second one doesn't get keyed in, stock vanishes without a trace and you only find out at the count.One transfer document with an in-transit status. Goods are recorded as on the move, so the sending warehouse has already gone down while the receiving warehouse doesn't go up until receipt is confirmed.
Batches and expiry datesNot there at all. Stock is treated as uniform, so 500 pcs expiring next month and 500 pcs produced last week are recorded as a single figure of 1.000.Every receipt carries its own batch number and expiry date. Issuing follows FEFO, and the system flags batches nearing the end of their shelf life before they turn into a loss.
Stock counts and variancesThe system figure gets edited directly to match the physical count. The variance disappears from the record the moment it's saved, so its pattern can never be analysed.A count runs as a document in its own right: the physical tally is recorded, the system calculates the variance, then an authorised person has to approve it before the balance changes. Variance history is kept permanently.
Unit conversionOne item, one unit. Buying by the carton and selling by the piece gets settled with manual maths outside the app, and the rounding differs depending on who's doing the counting.Tiered units with fixed conversion factors: buy per carton, store per pcs, sell per kilogram. The system does the maths, and conversion history is recorded whenever carton contents change.
POS and accounting integrationUsually standalone, or it only offers a CSV export. Sales figures and inventory values get retyped into accounting software at every month end.Connected to Moka, Olsera, Pawoon for sales, plus Accurate or Jurnal for inventory value via [API integration](/layanan/crm-integration). Anything without an open API we tell you about during discovery, not after the contract.
Tracing who changed stockMost of them only store the latest number. If a balance suddenly drops by 40 pcs, there's no way to know who changed it or on the basis of which document.Every movement records the person, the time, the source document, the value before, and the value after. Audit lines can't be deleted from any screen, including by an administrator.
Ownership of goods on the same rackAll goods are assumed to be yours. Supplier goods on hand and consignment stock get counted into inventory value too, so asset reports overstate your real position.Ownership becomes an attribute of its own. One physical pile can belong to several owners, and the inventory value report only counts what's genuinely yours.

// warehouse floor reality

Barcodes, small screens, and when the internet dies mid-shift

The core of a warehouse system isn't the item table, it's the movement ledger. We never store a balance as a single figure that gets overwritten — it's derived from a set of signed movements, so the stock card for each SKU per location can be reconstructed for any date in the past. Corrections go in as adjustment movements with a reason and an approver, not as edits that erase the trail. Here's where honesty is needed: the system makes variances visible, it doesn't make variances disappear. Most stock discrepancies are born in the process, not in the software — goods picked before the paperwork catches up, a unit misread, damaged packaging thrown out without a record, or losses nobody wants to report. What we can build is a tool for narrowing the dark corners: mandatory scanning at the receipt point and the exit point, routine cycle counts by category so discrepancies surface within days, and reports on variance patterns per person, per shift, per location. The rest is discipline, and discipline is yours to enforce. For the warehouse floor, the interface is designed mobile first — used standing up, one-handed, sometimes with gloves on — and it can be wrapped as an app installed on a phone. When the internet drops, receiving and picking keep running on the device and sync later, with conflict rules agreed in writing during discovery.

// how it works

From the first stock count to a system people trust

01

Discovery while walking the warehouse floor

1-2 weeks. We spend part of the session standing on the warehouse floor rather than in a meeting room — watching goods come off the truck, get counted, get put away, then get picked again. What we're chasing isn't the normal flow but the ones that deviate from it: goods arriving without a delivery note, a shipment one carton short, customer returns with packaging already damaged, or supplier goods on hand whose status isn't clear yet. We also count the basic numbers — how many locations, how many active SKUs, how many transaction lines per day, how many people touch stock. The output is a written scope document, and only from there does the price range narrow to a single figure.

02

Cleaning up master data and units of measure

The stage that gets underestimated most often, and it's almost always why warehouse projects fail. We audit your item list as it actually is: duplicate SKUs spelled differently, items carrying two codes because the supplier changed at some point, units that aren't consistent across sheets, and carton conversions whose contents changed once without anyone recording it. We hand the results back as a list of decisions — which ones get merged, which get retired, which carton quantity becomes the reference. Those decisions are yours to make, not ours. Until this list is signed off, opening balances can't be set and stock-module development doesn't run at full speed.

03

Two-week build sprints, warehouse flow first

Modules are built in the order goods travel: receiving, putaway, picking, shipping, then reports. Every two weeks there's a demo with modules you can genuinely click and scan. From the first sprint the testers are real warehouse staff, not the owner — because someone typing while holding a box has complaints you'd never think of from behind a desk. Button size, field order, and the scan confirmation sound usually change several times at this stage. POS or accounting integration is done after the internal flow is stable, so integration bugs don't get mistaken for flow bugs.

04

Opening count, balance migration, and UAT on staging

Stock balances aren't just migrated across from the old file — they're set by one full physical count whose result gets signed off. The old file still gets imported as history, but the opening numbers come from the physical count, because moving a number that's already wrong only moves the problem into the new system. Once balances are locked, your team uses staging for a few days with real transactions: receive goods, transfer, pick, return, then a trial count. Any variance that shows up at this stage we trace back to its source rather than quietly adjusting it. Bugs and usage confusion get resolved before go-live.

05

Phased go-live, role-by-role training, handover

The switchover starts with one warehouse or one product category, not the whole operation at once. The old records usually run in parallel for one cycle, until the system stock card and the physical count match for two periods in a row. Training is split by role: receiving staff don't need to sit through the management reporting session, and floor sessions happen in the warehouse itself on their own phones. Handover covers source code, the database schema, hosting credentials in your company's name, and documentation in Indonesian. Three months of bug fixes after go-live are already included in the project price.

// investment

Ranges, not packages

Compact system

Rp 15-30jt

One main location with 3-5 core modules: receiving, issuing, stock counts, stock cards, basic reports. One to three roles, basic barcode scanning, no third-party integration. A fit when what you're replacing is a few Excel files and a manual handover book.

Most commonly chosen

Rp 30-60jt

Multi-warehouse with inter-location transfers, batches and expiry, tiered unit conversion, count variance approval, plus integration with POS or accounting. This range usually suits distributors and retailers with 2-5 storage points.

Large scale

Rp 60jt+

Many branches or regional warehouses, high daily transaction volume, per-unit serial numbers, consignment stock belonging to several parties, and history migration from several sources. Usually split into several release phases so the switchover doesn't halt operations.

These are ranges, not packages, and none can be locked before discovery. Storage locations, batch or serial tracking, unit conversion, migration, and integrations determine the exact written quote. Full warehouse-system work starts at Rp 15jt; if an off-the-shelf Rp 2-5jt stock app meets the requirement, we say so and do not force a custom project.

// a good fit when

Which warehouses benefit most

  • →Distributors or wholesalers with two or more warehouses whose goods routinely move between locations
  • →Food, beverage, pharmaceutical, or cosmetics businesses that have to track batches and expiry dates
  • →Manufacturers whose raw materials are bought by the carton or the kilogram then consumed in smaller units
  • →Multi-branch retailers whose store stock is still reported by photo or WhatsApp message every afternoon
  • →Businesses storing supplier-owned consignment goods on the same racks as their own

// not a fit when

When an off-the-shelf app really is the right answer

  • ✕

    Single-location shops with one operator and goods that don't expire — buy an off-the-shelf Rp 2-5jt stock app, or use the built-in stock module in Moka, Olsera, and Pawoon. That's the right answer, and we mean it as a recommendation, not as small talk

  • ✕

    Anyone who needs a till and daily sales — that's POS work, and the POS products already on the market are far more mature than anything we'd build from scratch

  • ✕

    Anyone whose warehouse layout and flow still change every month — tidy up the physical process first, because a system will only lock the chaos in permanently

  • ✕

    Anyone who needs it live next month — discovery to handover is realistically 10-16 weeks, including the opening-balance count

  • ✕

    Anyone whose budget is below Rp 15jt and cannot move — we decline rather than cut scope until the stock numbers cannot be trusted

// questions

What warehouse managers usually ask.

We already use a Rp 2jt stock app. When is it time to move to a custom system?

Not when the app starts feeling unsophisticated, but when there's a question it can't answer at all. There are five signs, and they usually show up together. First, you have more than one storage place and transfers between them are recorded as two separate transactions. Second, some goods have an expiry date and you're starting to throw stock away for going past it. Third, one item is bought and sold in different units, and the conversion is done by hand. Fourth, count variances keep repeating and there's no data to trace the cause. Fifth, there are goods in your warehouse that aren't yours. If none of those apply, your Rp 2jt app is still the right tool — don't replace it.

Why is system stock always different from physical stock? Does a custom system guarantee zero variance?

No, and anyone promising that is selling something they can't deliver. Stock variances mostly originate outside the software: goods picked before the paperwork catches up, damaged packaging thrown out without a record, a unit misread at receiving, or losses nobody wants to report. What changes with the right system is that variances become visible faster and the dark corners get narrower — mandatory scanning at the receipt point and the exit point, weekly cycle counts by category so discrepancies surface within days rather than months, and reports on variance patterns per person, per shift, per location. The system gives you the evidence to fix the process. Fixing the process itself is still warehouse management work, not code work.

Can it connect to Moka, Olsera, Pawoon, Accurate, or Jurnal? What's realtime and what isn't?

Yes, and the split is worth understanding from the start because not all of it runs instantly. POS sales can generally be pulled in near-realtime via webhook or polling every few minutes, so stock goes down shortly after a till transaction. Inventory value and accounting journals are better sent as a scheduled overnight job, because accounting works by period and sending too often actually makes tracing harder. Item master data needs a human check: we build new SKU additions as an approval queue, so a wrong item code doesn't spread into two systems at once. What needs checking during discovery is the API documentation for the version you're on — some subscription plans restrict API access to certain tiers, and we tell you that before the contract, not after.

If the internet drops mid-shift, do warehouse staff stop working?

No, and this is actually the consideration most often ignored in tin-roofed warehouses or cold stores with poor signal. We build receiving and picking to run offline: scans are saved on the phone with the item and location list downloaded beforehand, then synced the moment the connection returns. What can't go offline is anything needing certainty at that exact moment — allocating the last stock across two different orders, or approving a count variance. Those parts still wait for a connection, because two phones that can't see each other could allocate the same goods. The conflict-resolution rules for syncing get written into the scope document for you to approve: which one wins, and which goes into a queue for a human to correct.

Do we need to buy dedicated barcode scanners, or are staff phones enough?

For most warehouses a phone camera is enough, and that's a real saving up front. We design the interface mobile first — big buttons, few fields, an audio cue when a scan succeeds, and one-handed operation while the other hand holds the goods. A dedicated handheld scanner only becomes worth it once you're scanning hundreds of lines an hour or floor conditions make holding a phone impractical; devices like that generally work as a keyboard, so the system doesn't need changing, just configuring. If your goods aren't barcoded yet, we set up internal label printing with your own codes. We give our device recommendations during discovery and you buy them straight from the seller — we don't take a margin there.

How is consignment stock or supplier-owned goods handled?

Ownership is built as an attribute of its own on each stock batch, separate from its physical location. That means one rack can hold your goods and goods belonging to two suppliers at once, but the inventory value report only counts what's genuinely yours — and the balance sheet doesn't overstate assets. When consignment goods sell, the system records the ownership transfer and raises the payable to the goods' owner at the same time, complete with a per-period recap you can use directly when reconciling with the supplier. Returning unsold goods also runs as its own document, not as a stock adjustment. This is one of the needs that most often forces businesses off off-the-shelf stock apps, because almost none of them provide it.

How are unit conversion and count variances handled so they don't become loopholes?

Conversions are stored as fixed factors per SKU with their history: a carton holds 24 pcs, a pcs weighs 250 grams. When a supplier changes the carton contents, the new factor applies from a specific date and old transactions aren't recalculated — this is exactly why a stock card can go completely wrong if the conversion is simply edited in place. For counting, the physical tally is recorded first without the user seeing the system number, so there's no temptation to adjust the count. The variance only appears after saving, and then an authorised person has to approve it with a written reason before it touches the balance. You set the value thresholds for whose approval is needed, and the whole variance history is kept permanently so patterns can be read per period.

How long does it take, and what most often makes it overrun?

A single-location system with core modules is realistically 10-12 weeks from discovery to handover. Multi-warehouse with batches, unit conversion, and integrations is usually 14-20 weeks. Broken down: discovery 1-2 weeks, build 6-12 weeks, UAT 1-2 weeks, go-live 1 week. What shifts the schedule most isn't the coding, it's the master data cleanup — an SKU list full of duplicates and inconsistent units can eat three weeks on its own, and most of that work sits on your side because only your team knows whether two codes are the same item or not. The second cause: the opening-balance count that keeps getting postponed because the warehouse is busy. Schedule those two from the start and the rest holds tight.

If we later need purchasing, production, and sales as well, do we have to rebuild?

No, as long as that direction is mentioned from discovery onwards. The warehouse module really is the heart of a larger system, and purchasing, production, and sales attach on top of the same data structure — which is why the data model decisions made early determine whether it can be extended later or has to be torn apart. The practice we normally take: build the warehouse first as phase one, run it until the numbers are trusted, then add the next module as a separate phase with its own scope and cost. This phased approach isn't a way of stretching the project out, it's a way of holding risk down — systems covering everything at once fail most often at UAT, because your team has to learn five new things in one week. The full direction is on the [ERP system page](/sistem/erp), and if a customer ordering module comes into it, an [online store](/layanan/toko-online) usually becomes the part connected later.

// go next

Related pages

Custom ERP Development Service

Build an ERP whose modules follow your own process: sales, purchasing, warehouse, production, finance. One database, one item master.

Composite narrative: a 6-day close down to 4 hours

Not a warehouse project; no consent reference or public artifacts are stored in the repository, figures are not independently verified, and results are not guaranteed.

Custom Business System Development

If daily operations still run on spreadsheets that clash and a manual scramble every month-end, what you need isn't another website — it's a system that follows how you already work.

// ready to start?

Build Your Business a Website
Right Now!

Free consultation via WhatsApp. We review your needs, give you a time & price estimate, then start together — no drama.

Free Consultation via WhatsApp → (opens in new tab)Check pricing

→ See examples of our workTerms & Conditions