Sales That Arrive From Another System — and How to Notice When They Stop

Most of your sales invoices may never have been typed by anybody in your accounts team. They come in from your online store, from EMP, from a marketplace shop, from a till that was offline, or from a spreadsheet somebody imported. This guide is for the person who looks after the books those documents land in. By the end of it you will know how each document shows where it came from, what it does to your books and what it does not, and you will have a five-minute morning check that tells you when a feed has stopped. For most feeds, nothing in BigLedger warns you when one stops: it simply delivers nothing, and that looks exactly like a quiet day.

Sales that arrive from another system, at a glance

Find out how each of your sales documents arrived: Created By, Created Date and Client Doc Type on the Sales Invoice listing tell a keyed invoice from a synced one; a marketplace order arrives as a sales order, and a till sale as a cash bill (Step 1).
Know what each way posts, and what it does not: a keyed, a synced and an imported invoice go through the same finalise step, and what differs is who presses FINAL, and whether anybody does; a document a hand-built integration creates already FINAL is the exception (Step 2).
Decide who watches each feed, and when: BigLedger keeps no list of the feeds you expect, so a person has to (Step 3).
Empty every offline till’s queue before the branch closes: reconnecting does not send it (Step 4).
Run the morning arrival check: yesterday’s count and total against the sending system’s, and the newest Created Date (Step 5).
Check that what arrived went all the way through: drafts, missing journals and the e-invoice, weekly and before month-end (Step 6).

Steps 1 and 2 are on this page. Steps 3 and 4 are on Who Watches Each Feed, and Steps 5 and 6 on The Morning Check.

Meet GadgetSphere

GadgetSphere Sdn Bhd (GS) keys very few sales invoices by hand. Its sales arrive four ways:

The online store run by GadgetSphere Online (GSO) sends every paid order to BigLedger as a sales invoice through the integration API — about 380 a day.
The distribution company (GSD) still raises its invoices in EMP, and they sync into BigLedger so that they can be e-invoiced from there.
Two marketplace shops arrive as sales orders on their own marketplace branch.
The two Kota Kinabalu branches (GS-KK-01, GS-KK-02) run their tills in Offline Mode, because the mall connection drops in the afternoons.

On a Monday in March the online store’s sync stopped at 14:10. Nothing on any BigLedger screen changed. The first person to notice was a customer, who scanned the QR code on her receipt on Thursday and was told the tax authority had no record of it. By then, 1,140 invoices worth RM 612,300 were sitting in the store and not in the books. This guide is about finding that out on Tuesday morning.

Before you start

You can open the Sales Invoice listing in Sales Invoice (Internal) for every company that receives synced sales.
You know every system that sends sales into BigLedger. If you do not, Step 1 is how you find out. Ask your administrator, or whoever set up each integration, for three things: the name of the login each integration uses, the branches it sends to, and where in the other system you can see a day’s total.
For each feed you have a daily count, or a daily total, from the sending system. This is the one thing BigLedger cannot give you, because BigLedger only knows what arrived. It is the number that makes the check work.

Three things to know first

A synced document is BigLedger’s copy, not the original. The original lives in the system that sent it. If the two disagree, decide which one is the master for that kind of document before anything goes wrong, and write it down. Usually the other system is the master and BigLedger keeps the copy.

Where a document came from is not one field you can filter on. An integration records its own name on every document it sends, but no listing shows that name. What you can see is who created the document and when, and the document type the BigLedger screen stamps on anything keyed through it. Step 1 shows how to read those.

Finalising is the same step, whichever way the document arrived. In BigLedger, saving a document does not post it. Finalising (FINAL) runs one set of checks and then starts the posting: stock, the journal, the receivable, the e-invoice. A keyed invoice and a synced one go through the same finalise step. What differs is who presses it, and whether anybody does — see Step 2.

    flowchart LR
  KEY["Keyed on a<br/>BigLedger screen"] --> SI["Sales invoice"]
  API["Integration API<br/>your online store"] -->|"can stay a draft"| SI
  EMP["EMP"] -->|"synced"| SI
  FILE["File Import"] -->|"blank status: a draft"| SI
  SI -->|"the finalise step: one set<br/>of checks, then the posting"| POST["Stock · journal, if your company<br/>posts one · receivable · e-invoice"]
  MKT["Marketplace shop"] -->|"arrives numbered and FINAL"| SO["Sales order on the<br/>marketplace branch"]
  TILL["Offline till"] -->|"Transaction Queue tab opened,<br/>15 minutes since the last send,<br/>or SYNC ALL"| CB["Cash bill"]

Step 1: Find out how each of your sales documents arrived

The outcome: for each way sales reach you, you know how to recognise its documents on the listing.

Sales Invoice (Internal) › Sales Invoice

Open the listing and bring three columns into view: Created By, Created Date and Client Doc Type. (If Client Doc Type is missing, an administrator has hidden it in the listing settings. Ask for it back, or ask for the permission that shows it.) Then sort by Created By.

How it arrived	How it shows on the listing	Where to read more
Keyed on a BigLedger screen	Created By is a person. Client Doc Type shows the screen’s own invoice type code, `INTERNAL_SALES_INVOICE`.	Sales Invoice (Internal)
Sent by another system through the integration API (your store, a booking system, a custom till)	Created By is the integration’s login, not a person. This is the login the integration’s access key belongs to, so it is the same name on every document that integration sends. Client Doc Type is whatever the integration writes there: a code of its own, or blank. Created Date is usually minutes after the Transaction Date.	Integration: Getting Started
Synced from EMP	The same as the row above. Client Doc Type reads `SALES_INVOICE`, without the screen’s `INTERNAL_` prefix, and the EMP Ref Number column (also on the invoice’s E-Invoice tab) points back to the EMP document.	This guide, Step 5
A marketplace order (Lazada, Shopee, TikTok Shop, Shopify)	It arrives as a sales order on the marketplace branch, not as an invoice, and it is already numbered and FINAL.	EcomSync Related Applets
Rung up on a BigLedger till	It arrives as a cash bill, created by the cashier. With Offline Mode on, it may reach BigLedger hours after the sale (Step 4).	POS General
Imported from a file (Sales Invoice › File Import)	Created By is the person who imported the file. The posting status comes from the file, and a blank status becomes a draft.	Sales Invoice (Internal)

If a document fits none of these — a login you do not recognise, and a type code that is blank or not one a BigLedger screen stamps — it came in some other way. The listing cannot tell you which. Ask your administrator which system owns that login before you rely on anything it sends.

The most common mistake at this step: assuming that any invoice with a type code was typed in by you. A BigLedger screen always stamps exactly INTERNAL_SALES_INVOICE. A different code, or a blank, means another system created the document, whoever Created By says it was.

Step 2: Know what each way posts, and what it does not

The outcome: you know which documents are finished when they arrive and which are waiting for somebody.

The checks and the posting behind FINAL are the same for a keyed invoice, an invoice sent through the integration API, an invoice from BigLedger’s standard integration intake and an imported invoice. They all go through the same finalise step. So a synced invoice for a customer with no e-invoice identity fails, or posts, exactly as a keyed one would. The differences are about who presses FINAL:

An integration can leave a document as a draft. A draft posts nothing and carries no running number, and nothing reminds anybody it is there. If you finalise it by hand, check first that the other system will not send it again.
Marketplace orders are FINAL the moment they arrive. No marketplace order waits for a person. A marketplace order with no running number is a run that failed, not an order waiting in a queue.
An imported file finalises only the rows it marks as final. A blank status column gives you a pile of drafts.
Whether FINAL writes a journal depends on how your company is set up, not on where the document came from. Some businesses use BigLedger for e-invoicing and operations and keep their general ledger somewhere else. For them, no invoice posts a journal, however it arrived. If you are not sure which kind of business you are, run the Missing Journal check in Step 6 on a keyed invoice first.

A document an integration creates already FINAL is handed to e-invoicing but not posted. This is a known defect BigLedger is tracking. BigLedger’s standard integration intake creates each document first and finalises it afterwards, through the same checks a screen uses. An integration you build should work the same way: create a draft, then call finalise. Today, though, the integration API’s create endpoints also accept a document that is already FINAL.

That document reads FINAL on every screen, but it has not been through the finalise checks, and no journal, stock movement or other posting job starts from it. Since mid-October 2026, one sent through the access-key endpoint (etl-ep) is still numbered and handed to the e-invoice job, so where your company e-invoices it can reach LHDN with no journal behind it. If the numbering or that hand-off fails, the create still answers success and the failure is only logged. A skip e-invoice setting on the customer or the branch is not copied onto it either, because that copy is made when a document is finalised.

While the defect stands, never create a document FINAL, and do not use a FINAL create to load history either. If an integration already does, have it mark skip e-invoice on each document that must not be e-invoiced until it is changed: a flag sent on the document is kept. If one of your integrations was built in-house, ask whoever built it which way it finalises. Step 6 catches a FINAL invoice with no journal either way.

What BigLedger will not do, and who does it instead

It will not tell you that a feed has stopped. Nothing compares what you expected with what arrived for an integration. The accounts person for each feed does that every working morning (Step 5), and knows it is fine when yesterday’s count matches the sending system’s.
It will not send an offline till’s queued bills by itself. The branch supervisor does, at close, with SYNC ALL, and knows it is done when the Transaction Queue is empty (Step 4).
It will not finalise a draft an integration left behind, or remind anybody it is there. The accounts person sweeps drafts by integration login every week (Step 6), and knows it is done when none is older than a day.
It will not compare your other system with BigLedger, unless the EMP missing-document report is set up for you, and then only for EMP. Everywhere else, the sending system’s day-end figure is the comparison, and the accounts person makes it. Where the report is set up, the same person notices the day its e-mail does not come.
It will not stop you keying a sale that the feed will deliver later. That rule is yours to keep: nobody re-keys a synced sale. The person who runs the integration re-sends it, and the accounts person confirms it arrived once (Step 5).

What success looks like

Run this at 10:00 on any working morning. It takes about thirty seconds per feed:

For every feed on your Step 3 list, yesterday’s count and total in BigLedger equal the sending system’s, and the newest Created Date for its login is from this morning.
Every offline till’s Transaction Queue was empty at close. The supervisor confirmed it, and did not just assume it.
There are no drafts from an integration older than a day.

If all three hold, nothing is stuck between another system and your books.

Common mistakes

Each mistake is on the page that covers it, in its Common mistakes in this part section: letting the integration’s owner sign off its own count, and clearing the browser on an offline till, are with Steps 3 and 4; reading “no errors” as “no problem”, re-keying the missing day, and trusting a list that has stopped updating are with Steps 5 and 6. The one that belongs to Step 1, assuming that any invoice with a type code was typed in by you, is at the end of Step 1.