When a retailer should set up ERPNext point of sale
A retailer should set up ERPNext point of sale when it wants till sales posted into the same books as its stock and accounting, instead of exported into a separate till system and reconciled by hand each day. POS is part of the core ERPNext platform, so it is not a separate product to buy, but the work is still a real project. It spans POS profiles that tie each outlet to a warehouse, price list, company and accounts, cashier sessions that open and close with a float and a count, payment methods that map to the right ledgers, and the way sales post to stock and accounting. Those choices shape how every till behaves, so they should be settled before the first live sale rather than adjusted under trading pressure.
The decisions to make first are concrete. Decide how many POS profiles you need and which warehouse, price list and default customer each one uses. Decide whether each sale updates stock and accounting immediately or whether invoices are consolidated at the end of a session or day, since that changes what a cashier sees and what finance sees at close. Decide which payment methods exist (cash, cards, vouchers, wallets) and which account each one posts to, and whether loyalty programs and promotional pricing must work at the till. Also confirm which roles can open and close sessions, apply discounts and see cost or margin, because the POS permissions are set through ERPNext roles rather than a separate till login model.
Treat the exact settings as version specific. POS screens, consolidation behavior, offline handling and the options for stock posting have changed between ERPNext releases, so confirm each one against the documentation for the version you run and the version you plan to run next. The ERPNext GitHub repository is the natural starting point for release notes. Before committing, run a pilot with one outlet, test returns, voids and end of day closing, and confirm with your own finance and store teams how the posted entries will reconcile with bank deposits.
What ERPNext POS does out of the box
ERPNext point of sale is assembled from a few connected parts: a POS profile that defines each outlet's settings, a cashier shift opened and closed with entries, and POS invoices that carry items, customers and payment modes to the till. Each block sets limits and posting behavior, so settle them together before the first store opens. Confirm the exact feature set for your ERPNext version in the POS documentation.
POS profile per outlet
A POS Profile holds the settings for one till or outlet: the company, warehouse, price list, default customer, allowed item groups and the payment modes offered. Create one profile per distinct stock location or pricing setup, because a single profile shared by several stores makes stock and price reporting harder to trust. Ask your team which fields change by outlet and which should be fixed centrally. Verify the field list in your version before you draft the profile matrix.
Cashier opening and closing entries
A POS Opening Entry records the float and the cashier at the start of a shift, and a POS Closing Entry reconciles the sales, payments and cash counted at the end. The closing entry is where cash variances surface, so finance needs a clear rule for who approves differences. Decide whether one cashier works one shift per till and how overlapping shifts are handled. Check how your version enforces opening before sales.
POS invoices at the till
A POS Invoice is the sales document created at the counter, separate from the standard Sales Invoice flow used for back-office billing. It is built from scanned or searched items, applied taxes and the selected customer, which may be a walk-in default. Decide which invoices require a named customer, such as for tax invoices or loyalty accounts. Confirm how returns and credit notes are raised from a POS invoice in your version.
Payment modes and tender types
Payment modes such as cash, card, bank transfer or mobile wallets are mapped to ledger accounts, so each tender posts to the right account when the invoice is submitted. Each POS profile can offer a different set of modes. Map every mode to a GL account and clearing account before testing, because a wrong mapping shows up later as a reconciliation gap. Ask your acquirer or wallet provider what settlement file they send, and confirm how your version handles split payments.
Item and customer selection
Cashiers select items by barcode, search or item group tiles, and the POS applies the price list and pricing rules configured for the profile. Customer selection can default to a walk-in account or require a lookup against the customer master. Define which item attributes must be complete before an item appears at the till, such as barcode, UOM and tax template. Test the search and barcode behavior with your real catalog size, since large catalogs change what the screen can show comfortably.
Configuration decisions to settle before the first till opens
This table compares the five design choices that shape an ERPNext POS rollout, with the conditions that favor each option and what it changes in reporting and month-end work. Read each row against your outlet count, stock control needs and accounting close calendar, then settle the choices in writing before profiles and payment accounts are built.
| Decision | Option and when it fits | What it changes in reporting and month end |
|---|---|---|
| POS profile scope | One profile per outlet fits stores with their own warehouse, price list, currency or cash accounts. Shared profiles fit a single outlet or a kiosk group with identical settings. | Per-outlet profiles keep sales, cash and stock separable by store. Shared profiles simplify setup but require cost centers or warehouse filters to split results later. |
| Stock and accounting posting | Real-time posting fits stores that need current stock on hand for replenishment and that run a single shared ledger. Consolidated posting fits high-volume outlets where a periodic summary invoice is acceptable. | Real-time posting puts every sale into stock and ledger immediately. Consolidated posting creates fewer summary entries, so reconciliation of individual receipts to the ledger needs a documented process. |
| Cashier session rules | Per-shift opening and closing entries fit outlets with individual cashiers who handle cash. A single shared session fits unattended or self-checkout use with no cash handling. | Each session produces a closing reconciliation. Expected cash, counted cash and differences are the main inputs finance reviews at close, so define who approves differences before go-live. |
| Payment method mapping | Map each payment mode to a specific bank or cash account per profile. Card settlements that arrive later may need a clearing account to match bank feeds. | Mappings determine which ledger account receives each tender. Errors here are hard to see until bank reconciliation, so test every tender type against the chart of accounts. |
| Loyalty program scope | Single program across all outlets fits a shared customer base and central marketing. Outlet-specific programs fit local brands or differing reward rules. | Loyalty points and reward costs post to accounts that must be planned in advance. Scope decisions affect how liabilities for unredeemed points are tracked and reported. |
| Offline operation | Confirm with the vendor and your own tests how the POS client behaves when the network drops, and whether sales can sync later without duplicate invoices. | Offline gaps delay posting and can shift sales between periods. Agree on a cut-off rule and an investigation process for unsynced transactions. |
How a POS rollout runs from design to go-live
The sequence moves from confirming the platform and hosting, through outlet and payment design, to a tested staging build and a single-outlet pilot, so each store is extended only after the previous step has been signed off.
Confirm ERPNext version and hosting model
Your team and the implementation partner agree which ERPNext major version you will run, whether you host on Frappe Cloud, with Docker Compose or with bench on your own servers, and which companion apps you need. Check the version against Frappe's supported versions list before anything else, because the support status of a release determines how long your POS configuration can stay on it. Sign-off output: a written version and hosting decision, with a list of installed apps and the environment owner named for each one.
Design outlets, warehouses and cashier roles
Map each store to a company, cost centre, warehouse and POS profile, and decide which stores share stock and which keep their own. Define who opens and closes a cashier session, who approves returns and who can change prices at the till. Confirm with finance how daily sales should reach the ledger, since that choice shapes the warehouse and account structure. Sign-off output: an outlet register that lists each store's warehouse, cash account, price list and role assignments, reviewed by finance and store operations.
Configure POS profiles and payment accounts
Create one POS profile per outlet, set its default warehouse, price list, currency and allowed payment modes, and map each payment mode to the correct bank, cash or clearing account. Set the item groups and customer groups each profile may use, and record which users can open it. Confirm the accounting treatment of card settlements with your finance team before mapping them. Sign-off output: a configuration export or screenshot for each profile, and a list of payment modes with their ledger accounts approved by finance.
Load items, prices and tax templates
Import the item master, barcodes, selling price lists and tax templates from your source system, using the Data Import tool in batches. The documentation advises importing only a few thousand records at a time, so plan the load in chunks and check each batch before the next one starts. Verify that every sellable item has a price in each outlet's price list and a tax template that matches how the goods are taxed. Sign-off output: a reconciliation report showing item and price counts per outlet that matches the source extract, with exceptions listed and resolved.
Test sessions, sales and returns in staging
On a staging site with the same version and configuration as production, run scripted scenarios: opening and closing entries, split tender, cash variances, discounts, voids, returns against an original invoice, and offline or interrupted sales if your hardware supports them. Check that stock movements and ledger postings match the expected results for each scenario. Also test any Server Scripts you depend on, noting that from version 15 they are disabled by default and must be enabled. Sign-off output: a signed test log with pass or fail results per scenario and a list of defects assigned to an owner.
Pilot one outlet with live hardware
Run one store on the production configuration for a defined period agreed in advance, with the cashiers you will train for the wider rollout. Test the actual terminals, card readers, receipt printers and barcode scanners on the store network, and record every exception, such as a failed session close or a mismatched cash count. Reconcile the pilot store's daily sales, payments and stock against the ledger before the end of each day. Sign-off output: a pilot report with reconciled totals, an incident list with resolutions, and a written go or no-go decision from operations and finance.
Extend to remaining outlets in controlled waves
Roll out the pilot configuration to the other outlets in groups, copying the approved POS profile pattern and changing only outlet-specific values such as warehouse, cash account and price list. Repeat the reconciliation check for each wave before starting the next one, and keep a change log so later edits to shared settings are traced. Train store staff on the procedures that the pilot confirmed. Sign-off output: a rollout log showing each outlet's go-live date, its first reconciled close and the owner of ongoing configuration changes.
Hardware, connectivity and offline questions to settle first
Before you choose ERPNext POS, settle what each outlet physically needs: receipt printers, barcode scanners, card terminals and the network they run on. Each device raises its own question. Receipt printers and barcode scanners are usually connected to the till computer, so the team should confirm which models and connection types the store already owns and whether the POS workstation can drive them. Card terminals are the harder decision. Ask the payment provider whether the terminal is integrated with ERPNext through a connector, or whether cashiers will key totals into a separate device and reconcile the payments afterward. That choice changes who builds the integration, how payment entries reach the accounts, and how refunds are handled.
Network reliability is the second question, and it should be answered per outlet rather than for the chain as a whole. Measure how often each store loses its connection, how long outages last, and whether the store has a second line. A POS session that depends on a live connection to the ERPNext server will stop when that connection drops, so the team needs a written answer to what cashiers do during an outage: keep selling and sync later, switch to a paper process, or pause the till. Do not assume that offline selling is available in your version or setup. Confirm the offline behavior of the POS in the Frappe documentation for your release, then test it on a staging bench with the same hardware, the same network path and a deliberate disconnection before you commit.
Once the outage behavior is known, decide how sales and payments will be reconciled after recovery, and who owns that task. Write down the expected duplicate-invoice risk, the cash handling rules when a session is interrupted, and the reports that finance will use to check the day's totals. Ask your implementation partner to include these checks in the test plan, and ask your hardware and payment providers to confirm in writing which models, drivers and integration methods they support with the ERPNext version you intend to run.
What drives POS effort and cost, and how to keep it down
This table lists the main drivers of ERPNext POS effort, what each one changes, and the levers that keep it down. Read it before requesting a quote, since each driver should appear in the written scope with a stated assumption. The biggest savings usually come from standard POS profiles, a limited pilot and one hardware standard.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of outlets and POS profiles | Each outlet needs its own POS Profile, warehouse, price list, payment methods and cost center mapping, so effort grows with outlet count and variation. | Use one standard profile template, copy it per outlet, and limit exceptions to documented differences. |
| Item and price volume | Large catalogs, many price lists and frequent promotions increase data preparation, validation and the risk of pricing errors at the till. | Load items with the Data Import tool in batches, keep one master price list, and move promotions into pricing rules only where needed. |
| Payment providers and their integrations | Each card terminal or gateway needs its own configuration, reconciliation rules and test cycles, and some integrations may need custom work. | Start with the payment methods your cashiers already use, and confirm each provider's ERPNext support before adding another. |
| Loyalty program rules | Tiers, points expiry, multiple collection rules and cross-store redemption each add configuration and test cases. | Begin with one simple loyalty program and add rules only after a pilot shows demand. |
| Hardware variety | Receipt printers, scanners, cash drawers, card terminals and tablets each need driver setup, testing and on-site support. | Set one hardware standard per device type and keep a tested spares list. |
| Custom print formats or scripts | Receipt layouts, Server Scripts and custom fields need design, testing and upgrade checks. Server Scripts are disabled by default from version 15 and must be enabled, and Frappe Cloud public shared benches do not allow them. | Use standard print formats first and confirm the hosting model supports any scripting before designing around it. |
| Number of users to train | Cashiers, shift leads and managers each need role-based training, and turnover adds repeat sessions over time. | Train a small group of store leads who can teach new cashiers, and reuse the same written cashier guide. |
| Offline and connectivity requirements | Offline selling and sync rules affect design, testing scope and the stock and accounting reconciliation process. | Settle the offline expectation during scoping, and test sync and reconciliation before go-live. |
Questions buyers ask before setting up ERPNext POS
How much more work is a multi-outlet POS rollout than a single store?
A multi-outlet rollout takes considerably more configuration and testing, because most POS settings repeat for every outlet. Each outlet needs its own POS profile, with its warehouse, cost center, price list, payment accounts and cashier users mapped correctly. The number of outlets, how many of them differ in products, taxes or payment methods, and whether each one posts stock and accounting in real time or in consolidated batches all change the effort. The usual approach is to build and prove one outlet end to end, then copy the proven pattern to the others with a checklist for the differences. Ask any partner to show how the scope counts profiles, outlets and test cases.
Can our own team configure ERPNext POS without a partner?
A team that already runs ERPNext stock and accounting can usually configure the POS profiles, items and payment methods itself, provided someone owns the design decisions. The harder parts are rarely the screens. They are the posting rules, the cash closing procedure, hardware drivers and the test cases for returns, discounts and failed payments. Teams often underestimate how many scenarios need a signed-off test. If your engineers have not run a POS rollout before, a fixed-scope engagement can cover design, build and testing while your team keeps ownership of the running system. DeployOpen implements inside your own infrastructure and agrees the scope in writing first.
What does the work need from store and finance staff?
Store and finance staff make the decisions that the configuration depends on, so their time matters more than their clicks. Store managers should define outlets, product ranges, prices, promotions, loyalty rules, accepted payment methods and the cash handling routine at opening and closing. Finance should define the accounts that receive sales, card settlements, cash differences and tax, along with the period close steps and who approves adjustments. IT provides hosting access, network paths to the tills, device enrollment and user accounts. Ask for a named owner on each side before the build starts, because unresolved decisions are the most common cause of rework.
How long does a POS pilot take, and what drives that timeline?
No single duration applies to every store, and the research behind this page does not give a standard pilot length, so ask for the timeline in the written scope. The main drivers are the number of outlets in the pilot, the number of POS profiles and payment methods, how many loyalty or pricing rules apply, whether card terminals and receipt printers need integration work, and how many stock and accounting postings must be tested. Pilot length also depends on how quickly the store and finance owners approve the design and how many test cycles the cash closing process needs. A pilot that runs with real cashiers for several trading days will surface more problems than one that runs only in a test site.
Do we need Server Scripts for POS, and how does hosting affect them?
Many POS setups do not need Server Scripts, but you should confirm that against your design before choosing hosting. Server Scripts run Python on document events or as API endpoints. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them, so a custom discount or receipt rule that depends on one needs a different hosting choice or a custom app. The ERPNext pricing page lists Frappe Cloud shared site hosting from 5 US dollars per month, servers for shared instances from 20 US dollars per month and dedicated servers from 125 US dollars per month, and self-hosting ERPNext is free. Compare those options against the features your POS requires.
How are returns and cash differences handled in ERPNext POS?
Returns and cash differences need a written rule before build, because the accounting result depends on how each case is recorded. Confirm in your ERPNext version how a return is created from a POS invoice, whether it reverses stock and payments the way finance expects, and how the cashier's closing entry records the gap between counted and expected cash. Decide who can approve a shortage or overage, the threshold that triggers a review, and which expense or income account receives the difference. Test each case in the pilot, including a return on a card payment, a return after a shift has closed and a cash shortage at the end of a day. These tests catch most of the disagreements between store and finance teams.
Which hardware and offline questions should we settle before go-live?
Settle the hardware list and the connection behavior before you choose hosting or write the design. List the till computers or tablets, barcode scanners, receipt printers, cash drawers, card terminals and customer displays each outlet uses, and confirm how each connects to ERPNext in your version. Then test what happens when an outlet loses its connection to the server during trading, and what cashiers must do to keep selling and to reconcile afterward. Ask the partner to show that test in the pilot rather than relying on a general statement. Hardware choices also affect support, so agree who replaces a failed device and who maintains drivers at each site.
How POS connects to stock, accounts, payments and other systems
Each POS invoice is a sales invoice in ERPNext, so it moves stock and the general ledger through the same mechanisms as any other sale. When a POS invoice is submitted with the stock update option on, the item quantities leave the warehouse named in the POS profile and the cost of goods sold is booked against the stock account. Income and tax land in the accounts defined in the profile and the item and tax templates, and receivables or payment accounts take the tender. Before go-live, have your finance lead run a test day and confirm that the stock ledger, the general ledger and the POS closing voucher agree for each outlet. Also confirm whether your outlets post invoices in real time or in consolidated form, because that choice changes how often the ledgers update and how much detail auditors see per transaction.
Customers, items, prices and tax rules are shared across ERPNext, so changes made in one module reach the till, but only after they are saved and synced. Item master data, item prices, price lists, pricing rules, customer groups and tax templates are read by POS when the cashier builds a basket. A price change made in the selling module may not appear at a till until the POS data cache refreshes, so test this on the actual terminal before you rely on it. Loyalty programs and their point rules are also ERPNext records, and they should be configured by someone who understands how points are earned and redeemed against invoices. Confirm with your implementation lead which records are read live and which are cached on the client.
Payment gateways, bank feeds, ecommerce platforms and loyalty services are not part of the core POS flow, so each one needs a named connector and a documented sync scope. Card terminals and payment processors typically return authorization results that ERPNext records as payment entries, but the exact fields and reconciliation behavior depend on the connector you choose. Bank feeds are handled by bank reconciliation, not by POS itself. Ecommerce orders may need their own import path. Review the ERPNext integrations group for the connectors documented for ERPNext, and for each one ask the vendor or the connector maintainer which records it creates, updates or deletes, how often it syncs, and how failed transactions are retried. Write that answer into the design before any hardware is ordered.
Access and login controls for cashiers and managers
Point of sale puts cashiers, supervisors and finance staff on the same records, so access has to be decided before the first till opens. The cards below cover the roles to define, the sign-in options ERPNext documents, and the policy questions that shared tills raise.
Cashier, supervisor and finance roles
Map each till job to its own ERPNext role before you create users. Cashiers need to open and close their own POS sessions and take payments, supervisors need to approve discounts, returns and closing differences, and finance needs read access to the resulting journal entries without the ability to edit till sessions. Test each role with a real sample transaction, including a return and a cash difference, before go-live. Confirm which permissions your partner should build as standard roles and which need custom rules for your outlets.
LDAP sign-in against your directory
ERPNext can authenticate users against Active Directory or OpenLDAP through LDAP Settings, with SSL/TLS options. Group membership is mapped to ERPNext roles at each login, so a store manager's directory group can drive their till permissions. Confirm which directory groups exist for each store and who owns them, because a wrong mapping gives a cashier supervisor rights they should not hold. Plan for what happens to a till session when a directory account is disabled mid-shift.
Social login for managers
Social Login Keys let users sign in through providers such as Google, Microsoft or GitHub, and through custom OAuth or OpenID Connect endpoints. This suits head office and remote managers who approve refunds from a phone. It is less suited to shared store devices, where a personal account would tie a till to one individual. Decide which roles may use social login at all, and confirm with your security team whether those accounts must be managed by your identity provider.
Server Scripts on shared hosting
Many point of sale customizations, such as blocking a discount above a threshold, rely on Server Scripts. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. If your rules need server logic, plan for a dedicated bench or a self-hosted deployment before you design the controls. Confirm this with your hosting choice early, since it changes what can be enforced.
Shared till policy questions
A shared till makes it hard to tie a payment or cash difference to one person. Settle these questions before configuring logins: will each cashier have a personal login, or will a device log in and cashiers use a PIN-style switch the platform supports, and who may close a session opened by someone else? Decide how long sessions stay open, who reviews closing differences, and whether a supervisor must be present for voids. Confirm the answers in writing with your finance and store operations leads.
Login policy for your environment
Password rules, session timeouts, two-factor requirements and lockout behavior should follow your own security policy and the hosting model you choose. Document who sets them, where they are configured, and how they apply to store devices that stay logged in. Test a lockout during a busy shift and confirm how a manager resets it. Ask your partner to record each setting and its owner in the handover pack so audits can trace it.
What to hand over at go-live and after
This sequence turns a working POS rollout into a handover that store operations, finance and IT can run without the implementation team on site. Each step produces a document or check that a named owner signs off before the next store opens.
Document the POS configuration record
DeployOpen exports a configuration record covering each POS Profile, the outlet and warehouse it draws stock from, the cost and income accounts it posts to, the price list, the users permitted to open sessions, and the mapping of every payment method to its ledger account. The client's finance lead reviews the record against the chart of accounts and confirms that each mapping matches how cash, card and wallet receipts reach the bank. Done means the record is versioned in the client's repository and signed off, with every change after go-live logged against it.
Compile the test evidence pack
The test evidence pack records each scenario run during user acceptance testing: opening and closing entries, cash and card sales, returns, discounts, loyalty point issue and redemption, offline sales where in scope, and failed payments. For each scenario it shows the expected result, the actual result and the accounting and stock entries created. The client's acceptance owner signs the pack, and any open defect is listed with its agreed workaround and a named owner for the fix.
Write cashier and manager runbooks
Cashier runbooks cover opening a session, recording a cash float, processing each payment method, handling a declined card, issuing returns and closing the session with a count. Manager runbooks cover approving discounts and returns, reviewing closing entries, correcting a mistaken session, and what to do when a terminal goes offline. Each runbook is tested by a store employee who was not on the project team. Done means that person completes the core tasks from the document alone.
Set up cash and card settlement reconciliation
The reconciliation routine compares the closing totals of each POS session with the cash counted in the till, and the card totals in ERPNext with the settlement reports from the acquirer or payment processor. It also checks that the day's payment entries match the bank feed or the bank statement. The finance team agrees the tolerance for differences, the owner of each exception, and the cut-off time for posting corrections. Done means the first full week of settlement reconciles, or every difference has a documented cause.
Confirm access, backup and monitoring responsibilities
The handover confirms which named people hold system manager, POS manager and cashier roles, how user accounts are removed when staff leave, and who can enable or change Server Scripts or other customizations. It also records backup schedules, restore tests already run, and where logs and background job errors are monitored. The client's IT owner signs the access and operations list. Done means every production administrator account traces to a named person, and the restore test result is in the pack.
Agree the support and upgrade model in writing
DeployOpen's support, upgrade and retainer options are scoped in writing, so the client knows which issues are covered, the response expectations agreed, how release notes for ERPNext and the POS components are reviewed, and who tests a minor or major version change in a non-production site first. The client should confirm the ERPNext version it runs against the Frappe supported versions page, because support coverage from Frappe depends on running a listed version and holding a matching support plan. Done means the scope document is signed and attached to the handover pack.
Hold the formal handover review
The handover review walks through the configuration record, test evidence, runbooks, reconciliation routine and support scope with the store operations, finance and IT owners. Each open item is assigned an owner and a date agreed in the meeting. The client accepts the handover in writing, and the implementation team confirms the knowledge transfer sessions are recorded. Done means the signed acceptance and the open-items list are both filed, and the production POS sites are released from the project's hypercare.
How DeployOpen scopes and delivers an ERPNext POS rollout
The written scope comes first, and it fixes the things that change cost most once a rollout is underway: the list of outlets, one POS profile per outlet, the payment methods each outlet accepts, the card terminals and receipt printers in use, and every integration that touches sales data. For each outlet we record which warehouse the POS profile draws stock from, which cost and income accounts post the sales, which cashiers open and close shifts, and whether stock and accounting post in real time or in consolidated batches. Loyalty programs, discounts that need approval, and any offline selling requirement are written down at this stage too, because each one adds configuration, testing and support work. The scope is agreed in writing before any build starts, and the quote follows from it.
Delivery runs in stages. A pilot outlet goes first, with a small set of cashiers, real opening and closing entries, and a daily reconciliation of the till, card settlements and ERPNext journal entries against the bank statement. Only after the pilot's stock movements and accounting postings match what finance expects does the rollout move to further outlets. Each stage has a go or no-go check agreed in advance, covering item and price sync, returns, voids, and end-of-day closing. Your team confirms hardware compatibility and the behaviour of your payment provider's integration with the ERPNext version you run, since those details depend on your environment and the current release, and we verify them on your devices during the pilot rather than assume them.
After go-live, support and upgrades can be handled through an optional retainer, which covers patching, ERPNext minor and major version work, and testing of new POS features before they reach the stores. Ask for the retainer terms in the same written document as the implementation scope, so that the recurring work, its response expectations and the exit terms are clear before you sign. Because ERPNext version support windows are published by Frappe, the retainer should name the version line being maintained and the process for moving to the next one.
