Category: Automation

Almost everyone who sells goods for cash or card eventually runs into the requirement to issue a fiscal receipt. And that’s where the familiar headache begins: one program to print the receipt, another to run sales and inventory. The cashier rings up the receipt in a POS app, then someone manually re-enters the same sale into the accounting system. Two programs, double data entry, and constant mismatches between the till and the books.

It doesn’t have to be this way. Fiscalization can be part of the ordinary sale — so the receipt goes to the tax authority straight from the system where you already track goods and money.

What a PRRO is, in plain words

A PRRO (programmable cash registrar) is, in plain terms, a cash register without the hardware: software that registers your receipt with the tax authority and returns a fiscal number. Instead of a separate cash register device, you use an online fiscalization service.

In Ukraine, the two most common PRRO services are Vchasno.Kasa and Checkbox. Both do the same thing: they take the sale data, register the receipt with the State Tax Service, and return a fiscal receipt that can be verified in the official registry.

If you sell goods to end customers, in most cases the law requires issuing exactly this kind of fiscal receipt. The only question is how convenient it is to do.

Why a separate till and ledger means extra work

The classic setup: the seller rings up a receipt in a POS program, and in the evening someone reconciles those sales with the accounting — to write off goods, see revenue, count stock. While there are few transactions, it’s tolerable. When there are dozens a day:

• the same sale is entered twice — first as a receipt, then as a movement in the books;
• the POS app doesn’t know your stock, and the ledger doesn’t know what’s already been rung up;
• every manual reconciliation is where errors are born.

The root of the problem: the receipt and the accounting sale are really one operation, artificially split across two programs.

How it works in ERPJS

In ERPJS, fiscalization is built into the sale itself. You record the sale as usual, and the system sends the receipt to the PRRO — Vchasno.Kasa or Checkbox, your choice — and registers it with the tax authority. No second app, no manual re-entry.

What happens in a single step:

• the sale is posted in the books — goods are written off stock, revenue goes into finance;
• the receipt automatically goes to the tax authority through your PRRO;
• the system gets back a fiscal number and a QR code the customer can use to verify the receipt in the official registry.

Setup is a one-time thing: you add your cash register, enter the access key from Vchasno.Kasa or Checkbox, and map your VAT rates. After that it runs on its own.

Paper receipt in store, electronic for online orders

The same mechanism covers two scenarios. In a brick-and-mortar store, the customer gets the usual paper receipt — with a fiscal number and QR code. In an online store, nothing needs printing: the receipt is electronic, and the customer gets a link to a fiscal receipt registered with the tax authority just the same.

All payment types are fiscalized: cash, card via terminal, and split payment.

Not just the receipt: the whole shift

• returns — a correction receipt is registered with the tax authority too;
• opening and closing the shift, generating the Z-report at the end of the day;
• cash in and cash out from the till.

All of it in one window, together with sales and inventory.

When a receipt was rung up outside the system

Sometimes part of the receipts were rung up elsewhere — from a courier’s mobile register or a phone. ERPJS has receipt import from Vchasno.Kasa: the system pulls receipts for a period and creates the matching sales itself. Nothing falls out of the picture.

The bottom line

When the PRRO is built into the accounting system, the sale, the stock, and the fiscalization are one operation, not three. Fewer programs, no double entry, and always a consistent picture: what you sold, what you wrote off stock, and what you registered with the tax authority.

Is a PRRO mandatory for my business?

In most cases, if you sell goods to end customers for cash or card, the law requires issuing a fiscal receipt. There are certain exceptions for some categories of entrepreneurs, so your specific case is worth checking against current State Tax Service requirements. If a receipt is required, ERPJS lets you issue it straight from your accounting system.

Do I need a cash register device if I have a PRRO?

No. A PRRO (software registrar) replaces the classic cash register: the receipt is registered with the tax authority through an online service — Vchasno.Kasa or Checkbox. There’s no separate hardware to buy.

How is Vchasno.Kasa different from Checkbox?

Both are PRRO services that register receipts with the tax authority. For working with ERPJS there’s no fundamental difference: you pick whichever service suits you and connect it. The integration works with either one.

How does the customer verify the receipt is genuine?

A fiscal receipt carries a QR code and a link to the receipt in the State Tax Service registry. Anyone can open the receipt through them and confirm it is officially registered.

Can I issue electronic receipts for an online store?

Yes. For online sales the receipt is electronic — the customer gets a link to a fiscal receipt, with no paper printed. This fully meets fiscalization requirements.

What about returns and closing the shift?

ERPJS registers not only sales with the PRRO but also returns, opening and closing the shift with a Z-report, and cash in and out of the till — the full cash cycle in one system.

Selling on Rozetka and Prom, but manually re-typing every order into your accounting software? Do your marketplace stock levels live separately from your real warehouse, so every now and then you sell something that’s already out of stock? This is the classic chaos of multichannel sales. In short: ERP marketplace integration removes it — orders flow into your accounting automatically, while stock and prices sync with your warehouse without manual work. Below we break down how it works and what to watch out for.

Why does manual work with marketplace dashboards eat into your profit?

Because every order passes through a person twice: first the manager sees it in the marketplace dashboard, then manually enters it into your accounting system. In parallel, someone has to remember to reduce the stock count. At 30-50 orders a day, that’s hours of routine work daily plus a constant risk of error.

The most expensive mistake is overselling. Until the manager updates availability, the marketplace keeps accepting orders for a product that no longer exists. What follows is order cancellation, a damaged seller rating, and on some platforms financial penalties too. One such case costs more than a month of manual syncing.

The second hidden loss is that you don’t see the real picture. Revenue in the Rozetka dashboard, revenue in the Prom dashboard, revenue in retail — these are three separate reports. Combining them into a single margin that accounts for commissions, delivery and cost of goods is practically impossible by hand. Decisions about assortment and pricing get made on gut feeling rather than numbers.

What is ERP marketplace integration and how does it work?

ERP marketplace integration is a direct data exchange between your accounting system and the platform through its API. Instead of manual copying, data flows automatically: orders from the marketplace land in your accounting, while stock and prices from your warehouse are pushed back to the platform.

ERPJS supports the two key marketplaces for the Ukrainian market — Rozetka and Prom.ua. Here it’s important to distinguish two data flows, because they work differently. Orders and new buyers land in your accounting in real time — the manager sees them in the system immediately, with no manual entry. The product catalogue, stock and prices, on the other hand, sync on a configured schedule: not an instant exchange, but also completely free of manual work. There’s no manual labour in either direction.

It’s important to understand the boundary of responsibility. The marketplace is the storefront: it shows the product to the buyer and accepts orders. The ERP is the accounting layer: it stores the real warehouse, cost of goods, finances, and consolidates all sales channels in one place. The integration is the bridge between storefront and accounting.

How does automatic order import free up your manager?

An order from the marketplace becomes a document in your accounting system in real time, and a new buyer is added to your contacts database without the manager’s involvement. The person no longer re-types data — they work with the order right away: picking, preparing for shipment, generating the waybill.

In ERPJS, the full order lifecycle is implemented first and foremost for Prom.ua: new orders are pulled in automatically along with their statuses, and buyers not yet in your database are created automatically. For Rozetka, the focus is on syncing the product side — catalogue, prices and stock (more on that below).

What this gives you in practice: instead of being a “re-typist”, the manager becomes an operator who processes ready-made orders. The freed-up time goes to what actually brings in money — fast shipping, customer communication, repeat-sales work. And once an order is in accounting, it’s easy to pass it further down the chain — for example, to immediately generate a shipment through our Nova Poshta integration, closing the full “order → delivery” loop.

What does syncing stock between warehouse and marketplace give you?

The main thing is that one warehouse becomes the single source of truth for all sales channels. Sell a product at a retail point or on another platform, and availability on the marketplace updates at the next sync. The risk of overselling drops sharply, and along with it go the cancellations, penalties and rating drops.

ERPJS pushes to the marketplace not just the fact of availability but the quantity too, and the calculation logic can be tuned to your process. For example, send the full physical stock to the marketplace, or stock minus already-accepted orders, or stock minus reservations. This matters if you sell from one warehouse across several channels at once and want to keep a safety buffer.

Prices sync the same way: you maintain the price list in your accounting system, and the current value for the chosen price list is pushed to the marketplace. No need to edit a price in three places — change it once in accounting and it propagates across channels. This is especially valuable during promotions and rapid repricing. If you’re only just putting your warehouse in order, start with inventory management software — without accurate stock levels, any sync will push wrong numbers to the marketplace.

Why run marketplaces through an ERP rather than the built-in dashboards?

Because the marketplace dashboard only sees its own channel, while the ERP consolidates all channels together with warehouse and finances. The Rozetka dashboard doesn’t know about your Prom and retail sales; the Prom dashboard doesn’t know about cost of goods and delivery expenses. Only in the accounting system do you see the real margin per product, factoring in marketplace commissions, logistics and purchase price.

This is a fundamental difference in approach. The marketplace’s built-in tools are optimised for selling on that specific platform. The ERP is optimised for your business as a whole: how much you actually earn, which products drag you into the red after all commissions, where you’re overstocked and where you’re short. The marketplace answers the question “what is selling”, the ERP answers “how much am I making from it”.

For a retail business going online this is especially relevant: the physical point and the marketplaces should live off one warehouse and one accounting system. How to tell whether your store has already grown into this kind of automation, we covered in a separate article on accounting software for a store.

What should you consider before implementing the integration?

The main thing is realistic expectations about stock synchronisation. Orders and customers land in your accounting in real time, but the catalogue, stock and prices update on a schedule rather than instantly: between a sale in one channel and the availability update on the marketplace there’s a sync interval. For most businesses this is non-critical, but if you trade scarce, high-turnover items, the interval is worth thinking through separately.

Second — the integration requires setup tailored to your warehouse and prices. The basic exchange framework is universal, but the fine rules — which warehouse to take stock from, which price list to push, exactly how to create new customers — are configured to your process. This isn’t “switch it on and it works out of the box”, it’s a setup project, albeit a small one.

Third — start in phases. First launch stock and price syncing (this removes the most painful part — overselling and price mismatches), then connect automatic order import. That way you get results fast and don’t try to cover everything at once. We recommend this approach for any ERP implementation — more on choosing a system in how to choose an ERP system.

Selling on Rozetka or Prom and tired of manual syncing? We’ll show you in a demo how orders from marketplaces flow straight into accounting, while stock and prices sync with your warehouse automatically. Request a demo →

Imagine: you’ve been using an ERP system for three years. All processes configured, employees trained, deal and document history — it’s all there. Then one morning you get an email: “The service is shutting down in 30 days.” What do you do?

This isn’t a theoretical question. SaaS business services shut down regularly — from small startups to large international products. For some users, it means 2-3 months of chaos and retraining. For others — a complete halt of operations. In this article, we’ll break down how “open source code” in ERP protects your business from this scenario — and how our model differs from classic open-source.

What “open-source ERP” usually means

When you hear “ERP with open source code” — usually it refers to large public projects: Odoo Community, ERPNext, Dolibarr. They share a common model:

• Public repository on GitHub or GitLab — anyone can download the code
• License (GPL, AGPL, MIT) — formally allows use, modification, distribution
• Community — thousands of developers worldwide
• Self-installation — you deploy the system on your server, configure it, maintain it

Sounds ideal — but there are nuances. Classic open-source ERP requires a strong IT team for implementation and support. For a business of 10-50 people, it’s often unaffordable: you need a DevOps engineer, a database administrator, developers for your industry. Or you hire an integrator — and again depend on a single contractor.

That’s why many small and mid-sized businesses choose SaaS — fast, no in-house IT team, support out of the box. But SaaS brings you back to the same vendor lock-in: your data and processes are with the vendor, and if something happens — you’re back to where you started.

How code access works in ERPJS

ERPJS offers two ways to work, and each addresses independence in its own way:

Option 1: SaaS on erpjs.biz. You sign up, get your company in our cloud, and start working within 15 minutes. The business logic code is on our servers — you don’t have direct access to it. This is a fast start, but you don’t have full control over the system — you depend on us as a SaaS vendor.

Option 2: On-premise installation on your server. We deploy ERPJS on your server — physical or cloud. And this is where the key point begins: the business logic code — documents, procedures, registers, reports, forms, validations — automatically ends up on your disk. Not “access on request,” not “we’ll send you an archive when you ask” — but simply files on the server that you have direct access to.

The business logic is fully readable JavaScript. Not minimized, not obfuscated. Any JS developer can open the files, read the logic, understand what’s happening. The system core (framework) is delivered as a built library — as is standard in the Node.js ecosystem. This is not a limitation: all industry-specific logic and processes can be adapted without touching the core.

This isn’t “open-source ERP” in the classic sense — we don’t have a public GitHub with thousands of contributors. But it is — technical accessibility of the business logic in your hands, which in practice gives you the same level of control over your processes.

What this gives you in practice

Let’s move from theory to specifics. Here are 4 consequences of having the business logic code on your server:

1. Any JS developer can work with the business logic. No need for a “certified ERPJS consultant.” The business logic .js files on your server are regular JavaScript. Hire a freelance developer, in-house, an outsourcing company — any option works.

2. You don’t depend on our roadmap. Need a specific feature for your industry, and it’s scheduled in our plan for next year? You can commission its implementation from any developer working with the code. You don’t wait for us.

3. You have a Plan B for any events with ERPJS. Service closed, we got acquired, war — doesn’t matter. Your system keeps running on your server. Support is provided by the developer you have now — or a new one you find.

4. Data + code = full control. This is the fundamental difference from pure SaaS, where you only have data, but without code you can’t change anything. And from pure open-source without a vendor, where you have the code, but all responsibility is on you.

By the same logic, we wrote about when Excel stops working — there too, the main risk is the absence of control. And if you’re just choosing an ERP — our guide 7 criteria for choosing will help you consider independence as one of the points.

SaaS or on-premise: which option is right for you?

These aren’t two stages of one path, as is often written. They are two different products for different segments — and you need to choose at the start.

SaaS is right for you if:

• You’re self-employed, a freelancer, or have 1-3 people on the team
• One location: coffee shop, salon, small store, service
• Simple product catalog, simple processes
• Control over code is not relevant to you — you need a fast start, not a long-term strategy

At this level, vendor lock-in is a theoretical risk: your processes are standard, the volume of data is limited, switching to another system if needed won’t be a catastrophe. Sign up, start in 15 minutes, work.

On-premise is the right starting choice if:

• You have manufacturing, distribution, a chain of stores, an auto service, a warehouse
• 10+ employees and multiple legal entities
• Complex processes, specific industry, possibly — integrations with other systems
• Regulatory requirements (pharma, medical, finance) or corporate security policy
• You understand that dependence on a single SaaS vendor is a business risk

Here on-premise is not “the next level when you mature,” but the right choice from the start. The earlier you’re on your own server, the less to redo as you grow. And the less risk if something changes with us.

Transition from SaaS to on-premise remains technically possible — for example, if you started as a small team on SaaS, and then the business grew. Data is transferred from SaaS to on-premise and back — it’s the same product, the same database. But it’s better not to wait until “we should have gone on-premise from the start.”

Who else can work on your ERP besides us?

This is where the story gets interesting for IT companies and developers. If a client has on-premise — the code is with them, meaning any external IT company can potentially maintain and extend it. This creates space for collaboration. Three formats we see as realistic:

Format 1: Referral. You bring a client to ERPJS, we handle them. Your role — sales and initial consultation.

Format 2: Implementation and customization. You as an IT contractor: implement ERPJS for the client, configure it for their processes, write specific modules. You get money from the client directly for your work. The business logic code is in your hands through the on-premise installation.

Format 3: Self-hosted SaaS. You take the code, deploy your SaaS under your own brand — for example, a specialized ERP for pharmacies, auto services, or beauty salons based on ERPJS. This is a white-label option.

Specific terms of cooperation for each format — individually, case-by-case. If you’re interested in discussing — write to us, we’ll figure out how it might look in your situation.

FAQ

An IT studio’s owner closes the quarter and reviews a project that “went fine.” Invoiced to the client: 800,000 UAH. Spent on it: team salaries 540,000, design subcontractor 120,000, infrastructure 25,000, two feature rewrites 85,000. Margin — 30,000 UAH, or 3.7%. The plan was 30%.

The problem isn’t the project itself — the problem is that this calculation was done three months after kickoff. Had the owner seen the real margin in week 5, they would have rescoped, deferred the subcontract, or stopped the rework. But the numbers lived in three systems: a time tracker for hours, Excel for the budget, accounting software for invoices. Reconciling them is a separate 4-hour job at month-end you never quite get to on time.

Project accounting in ERPJS solves this differently: budget, timesheets, costs, and invoicing — all in one system, with margin in real time. Let’s break down how it works, what it gives small businesses, and where the honest limitations are.

(A note for readers in regions with different delivery infrastructure: the patterns here apply broadly to IT services, consulting firms, agencies, and engineering practices. Currency examples use UAH because most ERPJS customers operate in Ukraine, but the underlying mechanics are currency-agnostic.)

Why do you only find out about losses at the end of a project?

IT studios, agencies, consultancies, and engineering firms typically run on this stack:

• Toggl / Harvest / Clockify — team time tracking
• Excel or Google Sheets — project estimates and budget
• QuickBooks / accounting software — invoices to clients, payroll, taxes
• Jira / Asana / Trello — task management

Each system has its own data, formats, and owner. Once a month someone (usually the owner or finance person) consolidates it into a pivot — and that’s when it turns out the project that “looked profitable” is actually on the edge. Or past it.

Specific problems caused by fragmented systems:

• Delayed diagnostics. Margin is calculated 3-6 weeks after actual spend. By the time you see it, you can no longer course-correct — only document.
• “Invisible” expenses. A 50,000 UAH subcontractor invoice went through accounting but never made it to the project’s Excel sheet. It doesn’t show up in the project report.
• Double data entry. The PM enters hours into Toggl, then transfers them to a client report, then the bookkeeper builds an invoice. One hour, three entries, errors at every step.
• Time silently bleeds into “non-billable.” Code review, meetings, rework — plenty of hours, none invoiced. Without time classification you can’t see the productive-vs-non-productive ratio.
• T&M invoicing is a separate ritual. Export from Toggl, filter, copy sums, manual invoice. 30-40 minutes per project per month.

An owner of a studio with 10 developers and 5 parallel projects loses 8-12 hours a month just reconciling these systems. And still ends up with a delayed picture.

How does ERPJS structure a project?

A project in ERPJS is a dedicated record with required attributes and a live link to the rest of the company’s accounting.

What the project card stores:

• Code and name — for fast lookup and document linking
• Customer — link to the contact record; internal projects leave this empty
• Project type — configurable by you (e.g., development, support, marketing, research)
• Phases / stages — a dedicated directory that the budget uses (more below)
• Team — list of participants and up to five managers (project lead, tech lead, account manager, lead designer, etc.)
• Customer contact — no need to dive into the CRM
• Dates — start, planned finish, actual finish
• Status — active / completed
• Hierarchy — a project can be a sub-project of another (useful for programs)

The card isn’t just a profile — it’s a hub. Budget, timesheets, purchases, invoices, and tasks all attach to it. Everything that happens to the project is visible in one place.

How do you plan a project budget from scratch?

A budget in ERPJS is a dedicated document with a matrix of work items and materials. Not an Excel sheet — a real accounting document with history, versions, and approval.

What goes into the budget:

• Services and labor (lines with hours and rates)
• Goods and materials (with purchase and sale prices)
• Breakdown by phase — each line is tied to a project phase
• Discounts for the customer

The system automatically calculates from the budget:

• Total of labor
• Total of goods and materials
• Overall contract value
• Expected profit
• Margin in percent
• Markup

Budgets support versions. This is an important detail: you draft plan A, then after negotiations with the customer create plan B with reduced scope, then a final approved version. All versions are preserved — you can compare what changed.

A separate “Approved” status — until a manager approves the budget, it’s a draft. Once approved, it becomes the baseline for plan-vs-actual comparison.

How do you see which time actually goes to the client and which doesn’t?

This is the question every IT studio or agency owner asks themselves. The team logged 200 hours on a project, the invoice charges the client for 200 hours — and the margin is still thin. Why?

Because out of those 200 hours:

• Some — meetings and discussions (not always billable)
• Some — code review and bug rework (rarely billable)
• Some — wait time, blocked on client responses (overhead)
• Some — onboarding a new developer to the project (an investment, not revenue)

In ERPJS, every timesheet entry has not just a project and hours, but also a time class — a category you define yourself. It’s a flexible mechanism: you create the classes that fit your business.

Common examples of how companies break time down:

• Billable — hours that go into a client invoice
• Non-billable / not recognized by client — rework, mistakes, out-of-scope work the client won’t pay for
• Internal — meetings, training, R&D, documentation, company events
• Idle — downtime, waiting for access or client responses

Each class can be tied to its own rate via the client’s price list. The timesheet report automatically groups data by class — and the owner sees at a glance:

• How many of those 200 hours actually went into an invoice
• How much was “eaten” by rework — a signal to rescope or retrain the team
• How much went to internal work — that’s investment, not loss, but you need to know the size of it

Separately — internal projects. For time that doesn’t go to a client at all (R&D, internal automation, your own product), you create a project without a customer. Time goes into the same timesheets but stays out of client analytics. This lets you cleanly separate: work for clients vs. investment in the company.

You define the classification — there’s no imposed structure. A small agency might use 2 classes (billable / non-billable); a large IT studio might use 5-7 (development, code review, meetings, training, support, pre-sales, etc.). Timesheets are approved by a manager — only approved hours flow into reports.

What costs automatically end up in the project?

Project costs come from three sources and feed the profitability report automatically:

1. Team time. All approved timesheets are multiplied by employee rates to produce total labor cost. If you use multiple time classes, all of them feed into costs (because labor is labor) — but the report shows the breakdown.

2. Purchases and subcontracts. Every supplier invoice (subcontractor, materials, infrastructure) has a “Project” field. If the purchase was created from a budget line — the project is pre-populated, no selection needed. If it’s a standalone purchase (e.g., an extra tester for a sprint), the PM picks the project at creation time. This is standard analytics-tagging for transactions.

3. Materials from stock. If the project consumes inventory items (client hardware, server gear, kits) — their issue from stock is recorded with the project link.

All of this rolls up automatically into the “Project Information” report — no extra exports, no manual reconciliation.

How do you invoice clients — Fixed Price or Time & Materials?

ERPJS supports both.

Fixed Price (per phase). The budget contains work lines tied to phases. When a phase is delivered — an invoice is created from those lines. An “Invoiced” field records the invoice number, so you can see which budget lines are already billed and which aren’t. Good for projects with a tight scope and milestone-based payments.

Time & Materials (per hour). The invoice is built from approved timesheets for a period, multiplied by rates. A dedicated procedure picks all hours classed as “billable” for a chosen month (or week) and creates an invoice with a per-day breakdown. You can run this procedure manually at month-end, or put it on a cron — monthly T&M invoices are generated automatically from approved timesheets, and the owner just reviews them before sending.

You can mix models within a single project — for example, fixed price for the main phases plus T&M for a separate support hours pool.

Which report shows real-time project profitability?

The “Project Information” report is the manager’s main tool. It shows, for a single project or aggregated across all:

• Revenue — total issued and planned invoices
• Costs — team time × rates + purchases + materials
• Margin in money — Revenue minus Costs
• Margin in % — how profitable the project is

This report updates in real time. The moment a new purchase is posted or a timesheet is approved, the numbers shift. That means: the manager can open the report any day of the week and see how the project is doing today, not last month.

You can also build it by phase — and see that phase 1 is on-budget, while phase 2 is already 20% over plan. That’s a signal to act now, before phases 3 and 4 repeat the pattern.

An aggregate report across all active projects immediately surfaces the least profitable ones. The owner sees at a glance where the team is losing money and can replan resources.

How do you plan team workload ahead?

A dedicated tool — the Resource Manager, a calendar planner with three modes:

• Month — workload overview across the team for 30 days ahead
• Week — day-by-day detail within the week
• Day — hourly breakdown inside the workday

How it works:

1. Employees are registered in the system as resources — each has a code, a work schedule, role information
2. Projects have tasks — with start dates, deadlines, and a list of assignees (one or several per task)
3. Each task has a type — development, testing, meeting, design, code review — types are configurable with colors
4. The Resource Manager automatically renders a calendar grid: rows are employees, columns are dates, colored blocks in cells are tasks by type

What’s visible at a glance:

• Who is overloaded next week (row packed with blocks)
• Who has free slots (empty cells)
• How task types are distributed across the team (e.g., did all testing fall onto one person?)
• Who is doing what right now

Clicking a day in the month view switches to hourly detail. Double-clicking a block opens the task (description, project, assignees, status).

On top of that — task workflow: when a task is closed with a specific result, the system can automatically create a follow-up task. For example: “development” closed → “code review” auto-created for a different assignee. Or “testing” closed with “needs rework” → “development” goes back to the original developer. That’s lightweight workflow automation without needing a separate Jira or Asana for small teams.

Honest limitations:

• Gantt charts with task dependencies (“A can’t start until B finishes”) — not supported. Dependencies are expressed via automatic result-based transitions (workflow), not as hard date links
• An “estimated hours” field on a task — not supported. Only start and end dates; duration is derived from those. If you need precise per-task hour estimates, that’s a current-version limitation

For teams up to 30 people running 5-15 parallel projects, this is usually enough. If your style requires Gantt with a critical path — ERPJS isn’t that choice today.

How does ERPJS integrate project accounting with company finance?

This might be the most important difference from specialized PM tools like Jira or Asana. Project accounting in ERPJS isn’t a side module — it’s part of the company’s financial accounting.

How it works: every project-tagged document (client invoice, purchase, timesheet, material issue) automatically posts journal entries in the chart of accounts with a “Project” analytical dimension. That means:

• P&L can be built for the company with a project-by-project breakdown
• Cash Flow is visible both for the company overall and per project
• Accounts Receivable by project — how much each client owes for this specific project
• No parallel accounting needed: a number can’t live in the project system and not exist in the books

This is the “single source of truth” approach — versus the typical Toggl + Excel + accounting software combo, where each system knows only its slice and the owner reconciles manually.

For the basics of financial accounting, see our post on financial accounting. For automating management reporting, see management accounting automation.

Where to start: a 30-minute first-project plan

A realistic plan: by the end of one workday you have your first project with timesheets and a budget. More precisely, a 30-minute minimum skeleton — the team fills in details later.

Step 1 (5 min): create the project. Card — code, name, customer, dates, type. Fill required fields, save.

Step 2 (5 min): add the team. Pick employees from the directory. Assign one or two managers.

Step 3 (10 min): plan the budget. Create a budget document, add 5-10 main work lines (e.g., “backend development,” “UI design,” “QA,” “management”). Enter hours and rates. The system computes total, margin, markup.

Step 4 (5 min): configure time classes. If not already set up — create 3-5 basic classes (“billable,” “internal,” “rework” — names are yours).

Step 5 (5 min): onboard the team to timesheets. Show them the timesheet UI. Employees log hours by day with project, work type, and time class.

After a week, you have approved timesheets, project costs, and the first margin picture. After a month — stable analytics across all active projects.

Frequently Asked Questions

An online store manager opens their inbox at 9:30 AM: 25 new orders overnight. Each one needs to be picked, packed — and an express waybill created on Nova Poshta’s website. That’s 5-7 minutes per waybill: log in, fill out the form, copy the address from the order into another tab, pick a branch, describe the cargo, enter the declared value and payment type. By lunchtime, the manager hasn’t started packing yet — they’ve only created waybills.

This is a typical morning for small and mid-sized e-commerce businesses in Ukraine. 25 orders × 6 minutes = 2.5 hours daily that you can reclaim — if your accounting system is integrated directly with Nova Poshta. Let’s break down how this actually works in ERPJS — without “everything is automatic” promises, with specifics about what’s automated and what isn’t.

(A quick note for readers outside Ukraine: Nova Poshta is Ukraine’s largest private delivery service, with 38,000+ branches and parcel lockers. The same integration patterns apply to other carriers — but in this post we focus on the Ukrainian use case where ERPJS already supports the full Nova Poshta API.)

Why does manually creating waybills kill a small store’s margins?

Manual work with waybills on the Nova Poshta website isn’t a single task — it’s a chain of five steps. Each one has room for error.

How much time it actually takes:

• Log in to the Nova Poshta cabinet — 30 seconds (sometimes session recovery is needed)
• Transfer order data into the Nova Poshta form — 2-3 minutes (address, phone, full name, weight, cargo description)
• Find the right branch out of 38,000+ — 30-60 seconds
• Calculate declared value and cash-on-delivery — 30 seconds
• Save and print the label — 30 seconds

That’s 5-7 minutes per waybill — assuming nothing breaks. Add a captcha or slow branch lookup in the cabinet and it stretches another minute or two.

Typical errors when entering data manually:

• Wrong address. The manager copied the previous customer’s address — the parcel went to the wrong person. Forwarding costs money and time.
• Incorrect declared value. The manager forgot to add VAT or entered the price of one unit instead of the whole order — the customer receives a parcel with an incorrect declared price, causing return-process headaches.
• Lost waybill number. The manager created the waybill but didn’t paste the number back into the order — a week later the customer asks “where’s my parcel?” and nobody knows which waybill it is.
• Duplicate waybill. Two managers created two waybills for the same order. One needs to be deleted, money refunded.

For a store with 30 waybills a day, that’s 2.5 hours of a manager’s work plus 1-3 errors per week. Errors cost: forwarding — 50-80 UAH; an additional customer contact — 10-15 minutes of the manager’s time; a lost customer — several hundred to several thousand UAH of forgone LTV.

How does ERPJS create a waybill from a sales order in one click?

In ERPJS, the Nova Poshta express waybill is created from a sales order or a shipment document. The manager opens the order → clicks “Create Express Waybill (NP)” → the system pulls all fields from the order data and sends the request to Nova Poshta. After 2-3 seconds the waybill is ready, the number is recorded in the order.

The key difference: the manager doesn’t leave ERPJS. No separate browser tab, no separate login, no separate copy-pastes. Everything happens in the same window where the order, the customer, the products, and the prices already are.

For details on inventory accounting from receipt to sale — see our separate post. The Nova Poshta integration is the next layer: a sale isn’t just written off from stock; it ships to the customer with a tracking number, all from one screen.

What is filled in automatically, and what does the manager enter manually?

This is the question where honesty matters more than the “everything is automatic” promise. Let’s break it down by field.

Automatic — from sender data:

• Sender city and branch (from your company settings in the system)
• Contact person, sender phone
• Cargo type (default — “Goods”)
• Who pays for delivery (from settings: you or the customer)

Automatic — from order data:

• Declared value = order total
• Cash-on-delivery amount = order total (if the customer pays on receipt)
• Customer legal entity — the system recognises a business client by the presence of EDRPOU (Ukrainian company tax ID) in the contact card
• Order number is linked to the waybill — later you can see which parcel belongs to which order

Manual — entered by the manager:

• Recipient city (if this is a new customer not in the database)
• Branch or full address (branch-to-branch or address delivery)
• Recipient full name and phone (if not in the customer card)

If the customer is a returning one with address and phone already in the database, the manager has almost nothing to enter — click, verify, confirm. Creating a waybill takes 20-30 seconds instead of 5-7 minutes.

How do city and branch directories work — fast or with delays?

This is an important detail often overlooked when choosing a system. Nova Poshta has 38,000+ branches and parcel lockers, hundreds of cities. If your system calls the Nova Poshta API every time you pick a branch, the search lags — especially on slow internet.

ERPJS does it the other way around: directories are stored locally. When you set up the integration, the system downloads the full catalog of cities, branches, cargo types, and payer types once — and stores it in its own database. Subsequent searches are instant: the manager starts typing “Lviv” — the system shows Lviv and all its branches in a fraction of a second.

Directory updates happen either by clicking a button in the admin module or automatically on schedule (every 1-2 weeks). New branches appear in the system without manager involvement.

What this means in practice:

• Branch search takes 2-3 seconds instead of 10-30
• The integration doesn’t depend on Nova Poshta API availability at the moment — even if Nova Poshta has an outage, you can keep preparing orders, the waybill will be created later
• The manager isn’t distracted from their main work by a “directory loading” wait

How are delivery statuses updated automatically?

Creating a waybill is half the job. The other half is knowing where it is now. In e-commerce this is critical: customers ask “where’s my order?”, the manager answers, marketing segments customers by delivery status.

ERPJS periodically queries Nova Poshta for the status of all active waybills. The interval is configurable — most commonly set to every 1-2 hours. The status updates in the order automatically: “Accepted for shipment”, “In transit”, “Arrived at branch”, “Delivered”.

How this looks in the workflow:

• The manager opens an order — sees the current delivery status without switching to the Nova Poshta cabinet
• You can build a report “all parcels in transit longer than 5 days” and proactively call those customers
• Marketing sets up automated emails — “your parcel has arrived at the branch”, “you received it — please rate your order”
• Accounting sees which cash-on-delivery orders have already been received — Nova Poshta will transfer the money in 2-4 days

Final statuses (delivered, returned, cancelled) stop being polled — the API load stays minimal.

Is thermal printer (ZPL) label printing supported?

Label printing is its own story. Small stores print on a regular office A4 printer — and that’s fine. Stores with 50+ parcels a day move to Zebra thermal printers (printing on 100×100 mm self-adhesive rolls) because it’s faster and cheaper — no toner, no print volume limits.

ERPJS supports both:

• Express waybill print (A4) — standard printing on a regular office printer. Suitable for an office shipping 5-20 parcels a day.
• Label printing for thermal printers (Zebra) — a specialised format for self-adhesive labels. The label prints in one click and is stuck directly onto the box.

The system marks each waybill as “label printed” — so you can see which orders still need a sticker and process all of them in one batch at the end of the day.

Can multiple stores or legal entities be connected?

Small businesses often have multiple legal entities: one sole proprietorship (FOP) for the marketplace channel, an LLC (TOV) for B2B sales. Each one has its own Nova Poshta cabinet and its own API key.

ERPJS lets you connect as many senders as you need. Each is a separate entry in the integration settings with its own API key, default city, branch, and settings. When creating a waybill, the manager chooses which legal entity to ship from — or it’s determined automatically based on the order (e.g., B2C → FOP, B2B → TOV).

This is especially useful when you’re scaling — adding a new brand, a new sales channel, a new legal entity. No need to switch cabinets with different passwords — it all lives in one system.

What delivery types are supported?

All main Nova Poshta modes are supported:

• Branch-to-Branch — the standard option for most orders
• Branch-to-Address — courier delivery to the customer’s door
• Address-to-Branch — courier pickup from your office or warehouse
• Address-to-Address — full courier logistics
• Cash on delivery — the customer pays on receipt; you get the money from Nova Poshta in 2-4 days
• Prepayment — the parcel ships already paid, without holding funds
• Goods return — a separate document type for customer-side returns

Honest about limitations: changing the branch of an already-created waybill via the API is not exposed in the form. If a customer asks to change the pickup point after shipping, that has to be done through the Nova Poshta cabinet. This is on the roadmap for future versions.

What about bookkeeping for delivery services?

This is where honesty matters more than promises. The Nova Poshta integration records the actual delivery cost of every parcel — useful for reporting and margin analysis. But it doesn’t create automatic accounting entries for delivery services: the bookkeeper has to record the total Nova Poshta service charge in your books each month separately.

Why: the entries depend on who paid for delivery (you or the customer), the payment method (card, bank transfer), and how it’s reflected in the VAT registry. There’s no universal logic — each company has its own delivery-services accounting scheme.

What this means in practice:

• The manager creates a waybill — the integration works automatically
• The bookkeeper gets a monthly report from Nova Poshta and posts the summary entry
• The integration already shows the total Nova Poshta charges for the period — useful for reconciling against the carrier’s invoice

This is the same approach most ERP systems take — automate the operational work (creating waybills, statuses) and leave the bookkeeper full control over what ends up in the General Ledger.

How to start the integration — a 30-minute setup plan

A realistic plan for connecting Nova Poshta to ERPJS — less than one workday:

Step 1 (5 minutes): get an API key. Go to your Nova Poshta cabinet → Settings → API → create a new key. Copy it.

Step 2 (5 minutes): add a sender in ERPJS. In the integration settings, paste the API key, pick a city, default branch, contact person. Save.

Step 3 (5-10 minutes): download directories. Click “Refresh NP directories” — the system pulls in all cities, branches, cargo types. This is a one-time setup.

Step 4 (10 minutes): test waybill. Create a single test order, try to create a waybill from it. Verify that the number appears and the label prints.

Step 5 (optional): enable automatic status updates. In the admin module set the status poll to every 1-2 hours. One-time setup.

After that, the integration is production-ready. Managers continue working in their familiar orders, but the “Create waybill” button removes 5-7 minutes of manual work per parcel.

What you get as a result

After a month of running the Nova Poshta integration, the store owner gets:

• ✅ Saves 2-3 hours of manager work daily (for a store with 30 waybills/day)
• ✅ Fewer address and data errors — everything is pulled automatically from the customer card
• ✅ Every waybill linked to a specific order — status lookups take seconds
• ✅ Real-time automatic delivery statuses — customers get answers fast
• ✅ Batch label printing at end of day — the manager works in waves, not one parcel at a time
• ✅ Support for multiple legal entities or stores in one system
• ✅ Delivery reports for analysis: average time, returns count, geography

If you ship more than 10 parcels a day, creating waybills manually on the Nova Poshta website already costs more than an integrated system. For 30+ parcels, the integration pays off in the first week.

If you’re just launching a store or planning a migration, start with inventory accounting and a basic store accounting program, and add the Nova Poshta integration once shipping volume becomes critical for your team’s time. POS with online fiscal compliance is a separate topic — covered in our post on integrated POS.

Frequently Asked Questions

Equipment rental without a system lives in an Excel sheet and a notebook: it’s unclear who has which specific unit, scheduled maintenance is forgotten, and disputes about damage become “your word against mine.” ERPJS has a dedicated “Rental” module that closes the entire cycle — from the customer’s order to the maintenance plan — and links all documents to each other.

Why don’t Excel and a notebook work for equipment rental?

Excel doesn’t distinguish “10 hammer drills” from “Bosch hammer drill SN-001, SN-002, SN-003.” There’s no way to keep history for a specific unit — who, when, with what runtime. A notebook records bookings but doesn’t show conflicts or remind about maintenance.

5 typical problems for a rental business with 50 units:

• Double bookings — an order accepted for an already booked date
• Damage disputes with the customer — no documented condition at check-out
• Missed scheduled maintenance — a drill ran 150 hours without service, breaks down with the next renter
• Invoice errors — 18 days rental billed as 17, or simply forgotten
• “Repair or write off” decision in the dark — no unit history or annual revenue

What should an equipment rental management system close?

6 functions in one cycle: unit catalog, booking with validation, rental contract with period and pricing, check-out/return acts with condition tracking, scheduled maintenance plan, automated periodic invoicing. ERPJS closes this in the “Rental” module.

How does the unit catalog look in ERPJS?

Each rental unit (Rental Object) is a separate card: code + serial number, manufacturer, model, year, location, meter type (HOURS / KM / CYCLES / NONE) and start value. Statuses: AVAILABLE / RESERVED / RENTED / MAINTENANCE / DECOMMISSIONED. Optionally linked to a Fixed Asset.

The module is universal — not only for equipment. Apartments, cars, exhibition equipment, containers, halls — any long-term rental. The same base logic applies. For hourly bookings (services) there’s a separate booking module.

How to see the rental pool load — Resource Manager

ERPJS doesn’t allow creating a booking for a period when the object is already reserved — code-level validation. So there are no “booking conflicts” in the system — they can’t be created.

To let managers quickly find free slots, there’s a Resource Manager — a visual calendar with month / week / day views. Each resource is a separate row, colored blocks are reserved periods. The manager opens the calendar, sees free slots and reserves there.

How are rental orders and contracts structured?

The cycle starts with a Rental Order (statuses DRAFT → CONFIRMED → CONVERTED → CANCELLED) — a soft document that captures the customer’s request without reserving anything. Upon confirmation it’s converted into a Rental Agreement — the main document of the module.

Agreement type: OUTGOING (we rent to a customer) or INCOMING (we rent from a supplier — the module is bidirectional). The agreement has 3 tabs: Rental Objects (with prices and period), Maintenance (service plan), Payment Plan (invoice schedule).

Statuses: DRAFT → ACTIVE → SUSPENDED / CLOSED / CANCELLED. Upon confirmation (OK), the system reserves objects for the dates and the agreement moves to ACTIVE. It can be suspended (SUSPENDED — during unplanned repair) and resumed. The agreement closes automatically (CLOSED) when all objects are returned.

From the document menu: Create Invoice, Calculate Payment Plan, Create Issue/Return Act, Suspend, Cancel.

How does scheduled maintenance work — the “Maintenance” tab?

Scheduled maintenance is a critical feature for a rental business. Without it, equipment breaks down with the customer in the middle of the rental.

The Rental Agreement has a dedicated “Maintenance” tab with a list of scheduled service tasks. For each:

• Service type — e.g., “brush replacement”, “air intake cleaning”
• Description — details
• Interval — in calendar days OR by meter reading (e.g., “every 100 motor hours”)
• Planned and last date
• Status: PLANNED → IN_PROGRESS → DONE
• Who pays: CLIENT (customer pays separately) or INCLUDED (bundled into rental price)

The meter-based interval works on real runtime: each return updates the new reading, compared with start — when the difference exceeds the interval, the system signals “time for service.”

Service work execution is handled in a separate Service Management module.

How is pricing set and invoices issued?

The price is always set per day — from the price list. The rental period (day/week/month + quantity) is not a tariff but the billing frequency: it defines how often to issue an invoice.

Example: price $50/day, period “month”, rental for 90 days → 3 monthly invoices. Or: price $20/day, period “week”, rental for 21 days → 3 weekly invoices.

The invoicing moment is also configurable: at the start of the period (prepayment) or at the end (postpayment). The “Payment Plan” tab shows the invoice schedule with statuses PLANNED → ISSUED → PAID. The “Create Invoice” command generates an invoice from the standard Sales module.

Payment is handled via invoices and prepayments. POS and fiscal receipts are not used for rental — rental isn’t retail. Financial control — through management accounting (planned vs actual revenue, customer receivables).

How is equipment condition tracked at check-out and return?

Rental Issue Act: condition at check-out, accessories and bundled items, meter reading, photos (as document attachments). Customer signs — it’s a legal document.

Rental Return Act: new meter reading (difference = runtime), condition at return, damage notes, missing parts, target status — AVAILABLE (back to the pool for next rentals) or MAINTENANCE (straight to repair without intermediate operations).

If the manager records damage or missing parts, or sets target status to MAINTENANCE — the “Has Issues” flag is automatically set. In the returns list, problematic items are immediately visible.

In any customer dispute — there’s a signed act with documented condition. Not “your word against mine.”

AI agent and MCP for rental managers

ERPJS supports the MCP protocol — an AI agent has direct read/write access to the system. The rental manager can ask the agent in Telegram without switching to the UI:

• “Which units are available from May 15?”
• “When is the next service for SN-001?”
• “Create a Rental Order for hammer drill SN-001 from May 15 to 17”

Documents are created as drafts requiring user confirmation. Real case — AI agent created 3 documents from a single Telegram message.

Frequently Asked Questions

Retail store owners are often offered two separate tools: a POS program for “punching receipts” and an accounting program for “bookkeeping”. It works, but every sale must be entered twice. In this post, we’ll discuss why this no longer works and what an integrated POS with online fiscalization looks like in ERPJS — using Ukraine’s Checkbox as the example.

Why is a standalone POS program no longer an option?

Real-life scenario: the cashier punches a receipt for 5 units. The POS sends the fiscal receipt to the tax authority — all good. But stock isn’t reduced, because warehouse software is separate. The accountant imports POS data via Excel in the evening, makes SKU mistakes, some receipts get lost. By month-end, stock is off by 30 units.

A standalone POS has 4 systemic problems:

• Double entry. Every sale must be recorded twice — in POS and inventory
• Time gap. Stock balance isn’t updated in real-time, only after import
• Lost receipts. If something didn’t import — sale exists in POS, missing in accounting
• Reports don’t reconcile. Bookkeeping and operational data live in different systems

An integrated POS solves this at the architecture level: a sale at the till is simultaneously a fiscal receipt to the tax authority, a stock deduction, and a cash-book entry.

How does online fiscalization through Checkbox work?

Checkbox is a software-based fiscal registrar (ПРРО) service that replaces a classic cash register for Ukrainian small businesses.

Flow:

1. Cashier rings up a sale in the POS interface
2. POS forms receipt data (items, prices, VAT, payment method) and sends to Checkbox API
3. Checkbox registers the receipt with the tax authority and returns a fiscal number
4. POS prints the receipt with the fiscal number or sends it to the customer electronically

Everything takes 2-3 seconds. No cash register, no thermal paper, no maintenance costs. The receipt has full legal validity.

Hardware POS vs Software POS — what’s the difference?

What does a POS integrated with accounting give you?

Every receipt in an ERPJS-integrated POS does three things at once:

1. Deducts stock. Balance updates instantly. With multiple locations, the system records which warehouse the item came from.

2. Sends the receipt to the fiscal service. The fiscal number appears in the system; the receipt has legal validity.

3. Forms a cash book entry with currency, payment method, margin. The accountant sees a finished day-end sales report — no import, no processing.

Details on tracking goods from receiving to sale are in a separate post. And a real example of how sales analytics surface anomalies is in our case study.

Which POS features are essential for retail?

Baseline POS feature set for a retail store:

• Quick buttons — top-20 items at one tap, no search
• Barcode scanner — search by EAN/UPC, auto-add to receipt
• Name search — fallback when the barcode doesn’t scan
• Discounts and promotions — % or fixed amount on item or whole receipt
• Multiple payment methods — cash, card, Apple/Google Pay, loyalty points
• Split payment — half cash, half card (one receipt)
• Returns — separate receipt type linked to the original sale
• Electronic receipt to email/SMS — customer gets a copy without paper
• Cashier change-over — mid-day (accountability)
• Z-report — close the shift in one tap

ERPJS POS works on a clerk’s laptop, tablet, or smartphone. Same interface — different device.

How to set up POS in ERPJS — in one day

Step-by-step plan for a store with inventory already in ERPJS, just adding the cash layer:

Step 1 (30 min): register with the fiscal service. Set up the company, get an API token. Tax-authority paperwork — standard.

Step 2 (15 min): connect to ERPJS. Paste the token in ERP settings, pick a register. Test receipt for 1 unit — to verify fiscalization.

Step 3 (1-2 hours): set up quick buttons. Drag your top-20 items into the POS interface. One-time setup — easy to edit later.

Step 4 (30 min): connect hardware. Barcode scanner via USB or Bluetooth. Receipt printer if you want one (optional with electronic receipts).

Step 5 (1 hour): cashier training. 5-10 test sales, returns, Z-report. The cashier learns the interface in 30 minutes — it’s intuitive.

Step 6: live day. First real day — watch the speed, adjust buttons. Within a week the POS becomes “invisible”.

How much does it cost?

Launch: nearly zero. The fiscal service is free to register, ERPJS POS is built-in.

Monthly subscriptions:

• Fiscal service (Checkbox): free tier for small businesses; paid tiers from ~USD 5/month
• ERPJS: free plan for start, paid by users and modules

Optional hardware:

• Barcode scanner — USD 25-60
• Receipt printer — USD 70+ (optional, electronic receipts work fine)
• Tablet stand — USD 15-40

A store starting from scratch is up and running for USD 100-300 in equipment + USD 5-15/month subscriptions. Compare to a classic hardware register: USD 200-400 upfront + USD 15-30/month maintenance.

What you get after three months

Three months into an integrated POS, the owner has:

• ✅ Accurate real-time stock balance — no weekly “guesstimate” audits
• ✅ Sales report for any period — one button, no Excel
• ✅ Margin per item and group — visibility into what makes money
• ✅ Cash book — no manual import, ready for bookkeeping
• ✅ Electronic receipts — customers get copies even after losing the paper
• ✅ Hardware savings — USD 200-400 less than a classic register setup

For the broader picture — see our recent “Accounting Software for Retail Store: 5 Signs It’s Time to Automate”.

Frequently asked questions

“ERP is for big corporations, we don’t need it.” This is the most common myth among small business owners. The reality is different: modern ERP systems have long scaled to businesses of any size — from 3 employees to 500. And often, small businesses need ERP the most, because they have fewer resources to absorb accounting errors.

In this article, we’ll break down what ERP really is in plain language, when a small business actually needs it, how much it costs, and how to start implementation without a big budget or complex projects.

What is ERP and how is it different from regular accounting software?

ERP (Enterprise Resource Planning) is a single system that unites accounting, inventory, finance, sales, manufacturing, and other business processes into one database. The main difference from separate programs: all modules work with the same data in real time.

A simple comparison:

• Separate programs: inventory software + accounting + Excel for sales + CRM. Data between them is not synchronized, you have to duplicate manually, reports don’t match.
• ERP system: sold a product → automatically written off from stock → accounting entry generated automatically → customer sees updated balance in CRM. One event — all modules updated.

ERPJS has 16 modules: goods accounting, inventory, sales, procurement, finance, manufacturing, CRM, service, POS, booking, rental, projects, HR, integrations (Nova Poshta, Checkbox), reports. All work in a single database.

Does a small business need ERP now, or is it for big companies?

Short answer: if you recognize yourself in at least 2 of the 5 signs below — you already need ERP. This is not about company size, but about process complexity.

5 signs that ERP is already needed:

1. More than 100 SKUs in inventory. Manual accounting of 100+ items stops being reliable — balances diverge, mis-sorting becomes normal.
2. Team of 5+ people working with accounting. When one Excel file is edited by several people simultaneously — versions start conflicting.
3. Excel file with 10+ sheets. If your main accounting is 15 interconnected Excel sheets, it’s no longer a spreadsheet but a shaky DIY ERP without integrity control.
4. You don’t know the real profit for last month. Net profit is counted by hand a week after the period closes — this is a sign of disconnected data.
5. You have multiple sales channels. Website + marketplace + offline + calls = if orders are collected separately, you lose control over inventory.

When Excel stops coping — we covered this in detail in the article “Excel vs ERP: When Spreadsheets Stop Working”.

How much does ERP cost for a small business?

The market price range for small business is from 0 to 200 USD per month for the entire company. Specific options:

ERPJS has a free plan with no time limits — this allows small businesses to start at zero cost and scale gradually. When the business grows — you move to a paid plan, but data and settings remain.

Which modules should you start ERP implementation with?

The main rule for small business: don’t implement everything at once. A gradual approach — from the biggest pain point to the full cycle. Here’s a proven sequence:

Stage 1 (month 1-2): inventory + sales. Set up the product catalog, enter stock balances, start issuing sales documents through the system. This already gives control over inventory and clean primary documents.

Stage 2 (month 3-4): procurement + finance. Add receipt documents, counterparts, bank statements. Now you have a closed loop “purchase → inventory → sale → payment”.

Stage 3 (month 5-6): CRM + analytics. Connect customer records, sales funnel, reports. At this stage, you start getting a real picture of the business.

Stage 4 (if needed): manufacturing, booking, POS, HR. Specialized modules are turned on when there’s a corresponding need in the business.

More about where to start business digitalization in a separate article. And principles of accounting for small business — in this post. For production-focused small businesses, see ERP for manufacturing.

Why is ERP better than a set of separate programs?

A typical “zoo” in a small business: QuickBooks for accounting + Excel for inventory + HubSpot for sales + Google Forms for booking + Telegram for customer communication. Looks functional, but has 4 systemic problems:

• Double data entry. An order has to be entered in CRM, then manually written off from inventory in Excel, then posted in accounting. 3 entries for one event — three times more time spent.
• No single source of truth. How much do we have in stock? Excel says 48, warehouse says 45, accounting says 50. Who do you trust?
• Real analytics impossible. To see profit per customer, you need to reconcile data from 4 systems — half a day of work instead of a “report” button.
• Risk of data loss. Google Forms can disable access, an employee left with access rights to Excel — part of the data is inaccessible.

In ERPJS these problems are solved architecturally: one database, one source of truth, reports generated in seconds. Management accounting becomes a system function rather than a separate quest.

What are the risks of ERP implementation for small business?

Honestly — there are risks, and you should know them in advance. Here are the three main ones:

Vendor lock-in. Classic closed-code ERPs keep your data in proprietary formats. If the price doubles — you have nowhere to go. In ERPJS business logic is open: data is yours, export is possible at any time, a partner or your developer can modify the system independently.

Data migration complexity. Moving 500 products, 2000 counterparts, and stock balances from Excel is 1-2 weeks of work. Solution: start with Excel template imports (ERPJS supports them) and incremental entry.

Team resistance. Employees are used to old processes and resist the new. Solution: implementation through a “change agent” (one person leads the project), gradual module activation, training before launch.

All three risks are manageable if you choose the right system and don’t try to implement everything in a month.

How to choose an ERP system for small business?

5 practical selection criteria:

1. Gradual implementation. Check if you can start with 1-2 modules and grow. Big-bang implementation is dangerous for small business.
2. Local adaptation. Tax rules, payment integrations, shipping — everything should work “out of the box” for your country, not through workarounds.
3. Integration API. Website, marketplace, payment gateway — the system should connect to your channels.
4. Open source or clear licensing terms. What happens if the vendor doubles the price? Can your data be migrated? Can you or a partner modify the system independently?
5. Support that understands your business. Small business needs support that gets your local context — not “ticket to India for 3 days”.

ERPJS meets all 5 criteria: gradual implementation (16 modules turn on separately), full localization, open API, open source business logic, and a partner network for customizations.

Frequently asked questions

Do your clients book appointments through phone calls, Viber, or Instagram Direct? Do you manage your schedule in a notebook or Google Calendar? Then you know these problems: forgotten requests, double bookings, employees unaware of new clients. There’s a solution — automating bookings through your website.

In this article, we’ll explore how online booking works in an ERP system and why it’s more effective than standalone scheduling apps.

Why don’t messengers and notebooks work for client scheduling?

When business is small — 5 clients a day — a notebook works fine. But as you grow, problems start:

• A client messaged on Viber, and you forgot to add it to the schedule. Result — the client arrived, but nobody was expecting them.
• Two clients booked for the same time. You checked available slots from memory, not from a system.
• The employee doesn’t know about the booking. A client booked last night via messenger — the technician only found out when the client was standing in front of them.
• No client history. What did they order last time? What were their preferences? Who served them?
• Finances are separate. Bookings in one place, payments in another, materials in a third. Impossible to understand service profitability.

Sound familiar? Then it’s time to switch to automated scheduling. As we discussed earlier — Excel and messengers stop working at scale.

How does online booking work in ERPJS?

ERPJS has a built-in booking module that lets clients schedule appointments through your website. Here’s how it works:

Step 1: The client opens the booking form on your website. They see available dates, times, services, and specialists. They pick a convenient slot and leave their contact details.

Step 2: The system automatically allocates resources. It checks the selected specialist’s availability, accounts for service duration, and blocks the slot for other clients.

Step 3: The employee receives a notification. Via Telegram, email, or within the system — in real time. No need to check the schedule manually.

Step 4: The client receives confirmation and a reminder. Automatic reminders a day or an hour before the visit — fewer no-shows.

See how it works in practice in our booking module video overview.

What does a business gain from automated scheduling?

Online booking isn’t just convenience for the client. It’s a tool that solves specific business problems:

Why is this better than standalone booking apps?

There are dozens of online booking apps: Calendly, Booksy, Altegio. They solve one task well — scheduling. But they share a common problem: they’re not connected to accounting.

In ERPJS, booking is part of a unified system:

• Booking → Service Order. A work order is automatically created from the booking with a list of tasks for the employee.
• Service → Materials. The system writes off consumables (parts, paint, supplies) from inventory. You know the cost of every service.
• Payment → Finance. The client invoice is created from the service. Payment goes into the General Ledger. Profitability — automatic.
• Client → CRM. Complete interaction history in one place: calls, visits, orders, invoices, payments.

Which businesses benefit from online booking?

The ERPJS booking module suits any business with time-based appointments + employee/resource:

• Service centers — repair scheduling, distribution between technicians.
• Beauty salons and barbershops — booking specific stylists, tracking materials.
• Medical clinics — doctor appointments, patient history, visit reminders.
• Sports clubs — class bookings, trainers, facilities.
• Auto repair shops — maintenance scheduling, lift allocation, parts tracking.
• Rental businesses — equipment booking for specific dates and times.

How to set up online booking on your website?

Setup takes a few hours:

1. Create a service catalog. Enter your services, duration, and pricing. For example: “iPhone screen replacement — 1 hour — UAH 2,500.”

2. Add specialists. Specify who performs which services and each employee’s work schedule.

3. Configure resources. If you have equipment (lifts, chairs, rooms) — add them as resources with availability schedules.

4. Embed the form on your site. ERPJS provides a widget or link to the booking form that embeds on your website.

5. Set up notifications. Choose how to notify employees (Telegram, email) and clients (SMS, email).

Watch the step-by-step setup guide in our booking configuration video. Learn more about capabilities on the client scheduling program page.

Frequently asked questions