How Skyline Nexus ERP works: one sale, end to end

Skyline Nexus ERP in one paragraph

Skyline Nexus ERP works by letting operational documents, such as purchases, sales, payments, expenses and payroll, create the accounting. Each saved document updates stock and tax records and, when automatic posting is switched on, generates a balanced journal in the general ledger. It matters because the ledger then reflects what the business actually did, not what someone re-keyed at month end.

This guide follows one small trading business through a month: two purchases, one sale, a customer receipt and a supplier payment. At each step it shows what the screen asks for, which accounts move and why, and where the result appears in the reports. The numbers are in euros with an illustrative 20% VAT rate, so every total can be checked with a calculator.

Two layers: operations and the Fiscal Authority ledger

Skyline Nexus ERP has an operational layer and a ledger layer. The operational layer is where staff work every day: Sales and POS, Purchases, Expenses, the Inventory Control Centre, Treasury and HCM. These screens create source documents with dates, quantities, prices, tax and a business location. The ledger layer is the Accounting module, which appears in the left menu under the divider Fiscal Authority and Compliance (GL) as the menu item Fiscal Authority. It holds the chart of accounts, journal entries, fiscal periods and the financial statements.

The link between the two layers is a set of listeners. When a document is saved, the matching listener builds a journal from it and posts it as a background job straight after the save, not in a month-end batch. That design is what the rest of this guide depends on, and it is also why the ledger reports, rather than the operational trading reports, are the ones an accountant signs. The operational Reports menu has its own Profit and Loss, which is a trading report built from documents; the ledger version is Fiscal Authority, Reports, Income Statement.

What is set up before the first document

Automatic accounting is only as good as its configuration. Before any document is posted, an administrator settles a short list of decisions, most of them once. The chart of accounts starts from a template picked at installation (Saudi, UAE or Generic) and can be extended or imported. The stock costing method matters more than it looks: FIFO is the IFRS-compatible choice, because IAS 2 does not permit LIFO, even though the setting offers both.

The most common implementation error is to skip the fiscal periods or the auto-post switches. Without a fiscal period covering the document date, a posting is refused. With the switches left off, which is the default, documents are saved but the ledger stays empty. Both are easy to fix and easy to overlook.

• Business Settings: the business Currency, Financial year start month, Stock Accounting Method (FIFO or LIFO) and Transaction Edit Days
• Business Locations: one per branch, each with its invoice schemes and payment methods
• Chart of accounts: template accounts plus your own, each with a GL Code and Account Type
• Fiscal Authority, Settings, General Settings: default cash, bank, receivables, payables, sales, cost of goods sold, inventory and VAT accounts
• Product categories: optional GL Sales Account and GL COGS/Purchase Account per category
• Fiscal Authority, Fiscal Periods: a fiscal year with monthly or quarterly periods
• Auto-Post Settings: the toggles for sales, purchases, payments, expenses, payroll, depreciation and disposals

Step 1: two purchases create two stock lots

On 1 March the business receives 100 units of a product at EUR 40 each, plus VAT, and on 10 March another 100 units at EUR 44 because the supplier raised its price. Each received purchase does two things. In stock, it creates a lot at the location that received the goods, recording quantity and tax-exclusive cost. In the ledger, with Auto-post Purchase Transactions on, it debits inventory with the cost, debits the VAT Input Account with the recoverable tax, and credits accounts payable with the total the supplier is owed.

Keeping the two lots separate is what allows the cost of a later sale to be calculated rather than estimated. The input VAT is taken line by line using the same calculation the tax reports use, so the VAT Input Account and the VAT return start from the same figures. Our guide on how to record a purchase covers what the Received, Pending and Ordered statuses mean for this step.

• Purchase 1, 1 March: Dr Inventory 4,000 / Dr VAT input 800 / Cr Accounts payable 4,800
• Purchase 2, 10 March: Dr Inventory 4,400 / Dr VAT input 880 / Cr Accounts payable 5,280
• Stock after both: 200 units, EUR 8,400 at cost, in two lots of 100

Step 2: the sale consumes lots and posts revenue, VAT and cost

On 15 March the business sells 150 units at EUR 70 on credit: EUR 10,500 plus VAT of EUR 2,100, a total of EUR 12,600. Only a final sale posts; drafts, quotations and proformas are skipped. With Auto-post Sales Transactions on, the sale produces two balanced pairs. The first recognises the receivable, the revenue and the output VAT. The second moves the cost of the goods out of inventory into cost of goods sold, valued at the tax-exclusive cost of the lots the sale consumed.

Under FIFO the sale consumes all 100 units of the first lot at EUR 40 and 50 units of the second at EUR 44, so cost of goods sold is 4,000 plus 2,200, which is EUR 6,200, and gross profit is 10,500 minus 6,200, EUR 4,300. The 50 units left are valued at EUR 44, EUR 2,200, which agrees with 8,400 minus 6,200. Had the business chosen LIFO the cost would have been EUR 6,400 and profit EUR 200 lower; under IFRS that option is not available, because IAS 2 does not permit LIFO, so FIFO is the setting to use. If product categories carry their own GL Sales and COGS accounts, revenue and cost are split by category automatically.

• Dr Accounts receivable 12,600 / Cr Sales revenue 10,500 / Cr VAT output 2,100
• Dr Cost of goods sold 6,200 / Cr Inventory 6,200
• A POS sale paid fully in cash debits a cash-sales clearing account instead of accounts receivable

Step 3: payments settle the balances

A payment is a separate record from the invoice. On 30 March the customer pays EUR 12,600 by bank transfer and the business pays the first supplier EUR 4,800. With Auto-post Payment Transactions on, each payment posts its own journal: the receipt debits the bank and credits receivables, and the supplier payment debits payables and credits the bank. Deleting a payment reverses its journal rather than erasing it.

Keeping invoices and payments apart is what makes ageing reports possible. The AR Aging Report and AP Aging Report sort each open document into current, 1-30, 31-60, 61-90 and over 90 days. At the end of March the second supplier invoice of EUR 5,280 is the only open item.

• Customer receipt: Dr Bank 12,600 / Cr Accounts receivable 12,600
• Supplier payment: Dr Accounts payable 4,800 / Cr Bank 4,800

The trial balance at 31 March

Because every document posted a balanced journal, the trial balance at 31 March balances without any month-end entries. Debits total 7,800 plus 2,200 plus 1,680 plus 6,200, which is EUR 17,880. Credits total 5,280 plus 2,100 plus 10,500, also EUR 17,880. The VAT position is output VAT of 2,100 less input VAT of 1,680, so EUR 420 is payable for the period.

The same figures drive the statements. The Income Statement shows revenue of 10,500, cost of goods sold of 6,200 and gross profit of 4,300. The Balance Sheet shows bank, inventory and VAT recoverable on the asset side, payables and VAT output on the liability side, and the profit in equity. Our guide on trial balance to financial statements explains that journey in general terms.

• Bank: Dr 7,800 (12,600 received less 4,800 paid)
• Inventory: Dr 2,200 (50 units at EUR 44)
• VAT input: Dr 1,680
• Cost of goods sold: Dr 6,200
• Accounts payable: Cr 5,280
• VAT output: Cr 2,100
• Sales revenue: Cr 10,500
• Totals: Dr 17,880 = Cr 17,880

Expenses, payroll and assets join the same ledger

The same pattern applies beyond trading. An expense posts to the GL Expense Account set on its expense category, and if a category has no GL mapping the posting fails with an error rather than landing silently in a default account, which is the safer behaviour for an auditor. Processed payroll posts salary expense and salaries payable, and in Saudi Arabia the GOSI accounts. Depreciation runs monthly in Asset Management and posts when Auto-post Depreciation Entries is on; disposals post gains and losses.

Some operations are managed in the stock screens and their value effect is handled by your accountant. Stock transfers between locations move quantities between branches; stock adjustments and opening stock depend on a back-end setting, so confirm with your implementation contact whether they post for your business and otherwise record a write-down by manual journal. Our guides on automatic journal entries in Skyline Nexus ERP and on multi-branch accounting go into both.

Controls that are built into the flow

Skyline Nexus ERP builds several controls into this chain. A fiscal period that has been closed or locked refuses any new posting, so the March figures stay as they were when March was closed; a sale dated in a closed period is still saved as a document with its journal refused by the close, and to bring it into the ledger you reopen the period, then edit and save the document so that it posts. Posted journals are never deleted; they are reversed, which leaves both entries visible. Sales are soft-deleted to a Recycle Bin after their journals are reversed, and an invoice already reported to or cleared by ZATCA can only be corrected by credit or debit note.

Every change to a journal is written to the Audit Trail, with the user, the old values and the new values, and the core system keeps a separate Activity Log of document changes, deletions and logins. Our guides on the audit trail and on fiscal year and period close in Skyline Nexus ERP explain each control and how to review it.

Proving the ledger matches the documents

Automatic posting removes re-keying, but a finance manager still needs proof that every document reached the ledger. Skyline Nexus ERP provides that proof in Fiscal Authority, Reports. Data Verification compares the trial balance, general ledger transactions and POS transactions. The Day Book's Gap Analysis, headed Audit Inspector on screen, scans posted journals for broken links to their source documents and for amounts that do not match the source. All Transactions gives one list of every business transaction for audit review.

For tax, the VAT return form under Reports is prefilled from the sales, purchase and expense documents, and VAT Analysis reads the VAT GL accounts; the two are computed on the same basis, so a difference points to a document that did not post. Running these three checks before closing a month catches a switched-off toggle, a missing account mapping or a document dated into a closed period.

• Data Verification: trial balance versus GL transactions versus POS transactions
• Day Book Gap Analysis: posted journals whose source document is missing or does not match
• VAT Analysis against the VAT Return form for the same dates and location
• AR Aging Report and AP Aging Report against the receivable and payable control accounts