Support & Troubleshooting
Find answers to common questions here, and know where to go when the documentation does not cover your problem.
Start here
Troubleshooting
Troubleshooting lives with the thing that breaks, not in a separate section. Each applet reference page carries a Troubleshooting section naming the errors that applet actually produces and what to do about them — start from the applet you were using when the problem appeared.
Getting help from a person
Open an issue at BigLedger-Support/public — BigLedger’s public inquiry tracker. Anyone can post there, you can see what other people have already asked, and the answer stays visible for the next person with the same problem. Say which applet you were in, what you expected to happen and what happened instead. Because anyone can read it, keep your tenant code and your own records out of the post: a question about the product belongs there, a question about your own tenant does not.
Your BigLedger contact — the person or partner who onboarded your company — is the fastest route for anything specific to your tenant: permissions, e-invoice authorisation, applet registration, or data questions. They can see your configuration; the documentation cannot. If nobody in your organisation knows who that is, ask for the contact on the tracker — that question carries no detail of your own, and the answer gives you a private route for the one that does.
Our service commitment
This commitment covers questions raised on the public tracker, BigLedger-Support/public.
Every new issue gets a first response within three Malaysian business days — Monday to Friday, excluding Malaysian public holidays. The first response is an acknowledgement or a first answer: it tells you the question has been read and, where the answer is short, gives it. It is not a promise of when the matter will be resolved, because that depends on what the question turns out to be.
After that, the issue is triaged, labelled and answered in the open, and the answer stays visible for the next person who asks the same thing. If we need more from you to answer, we ask on the issue.
It does not cover anything specific to your own tenant — permissions, authorisations, your data, or documents that need repairing. Those go to your BigLedger contact, as the section above says, because they can see your configuration and work on it privately.
If your company has a support agreement with BigLedger, that agreement sets the terms of your own support, and where the two differ, your agreement applies. The three-day target is what we aim for on the public tracker. It is a target, not a contractual guarantee.
When the only answer is support — and exactly what to send
Pages across this wiki end a fix at ask support, ask your BigLedger contact or ask your administrator. That is an honest ending only if the page says why you cannot do it yourself and what to put in the message, so here it is once, and every page that points here means it.
First, check it is not yours to do after all
Suppose your request is “a background job is not running on my tenant”: an e-invoice sweep that never fires, a replenishment run that never happens, a notification that never goes out. Check this before you write. The schedule itself is a row in your own tenant’s cron table, and the Scheduler applet writes it. If Scheduler is in your applet list and you hold the schedule-create permission, you can add the clock yourself: *Scheduler →
- → click Scheduler Code → pick the processor from the Select Processor picker → set the cron expression → Status ACTIVE*. That picker is also the only screen in the product that shows you which job processors your tenant actually has, which is worth knowing before you ask anyone anything.
Read the Scheduler listing before you press +. If a row for that processor is already there, the question is why it has not fired — its Last Run Date is where that starts — not whether to add one. Nothing in the product stops you creating a second row for the same processor, and if you do, both of them fire.
If Scheduler is not in your menu, or + is refused, that is not a request to us. Applet access comes from the Applet Store and the permission from Settings → Permission Set / Role Permission — both inside your own tenant, and both your own administrator’s to grant. Ask them before you ask us — that distinction is the last section of this page.
Do not stop there, and do not guess the rest from this page. The cron expression is parsed with the UNIX five-field definition, a new schedule’s first firing is computed forward from the moment you created it, a job that needs properties takes them on the row’s Json tab, and Run — on the schedule’s Edit screen — fires it once so you find out today instead of tomorrow. All of that, and how to tell a schedule that never fired from one that fired and failed, is on the Scheduler applet page, including how to try it safely first. Which processor you need is on the page for the thing that is not happening — the Peppol guide names the Peppol sweep, the e-invoice applet page names the e-invoice ones.
What you cannot do from there is make a processor appear in that picker in the first place. So the honest split is:
| The thing you want | Who can do it |
|---|---|
| Schedule a processor that is already in the Select Processor picker, change its cadence, or run it once now | You, in the Scheduler applet |
| See which processors your tenant has at all | You — the Select Processor picker |
| Make a processor available to your tenant that is not in the picker | Us. No screen in the product does it |
| Start the pacemaker that reads the cron table at all — the symptom is that nothing scheduled has run, on any processor. Press Run on one schedule before you ask: if Run works and nothing ever fires on its own, the cron path is the broken half, and that sentence is what to send | Us |
| Install an applet that is not in the Applet Store | Us |
| Write a credential, token or seeded reference row that sits outside every screen you have | Us |
| Repair documents that have already been written | Us |
What to send
The rows that end with us need different things, because different things have to be built at the other end. Sending the wrong bundle costs you a round trip.
Which “us”? Your BigLedger contact for anything naming your own tenant — that is every request on this page. The public tracker is for a question about the product itself, and because anyone can read it, keep your tenant and your data out of the post.
A processor that is not in your picker, or a schedule only we can create. A schedule row holds three things: a processor code and a cron expression, which it will not save without, and the properties the job may need when it runs. Name all three, then your tenant:
- the processor code, exactly as you have seen it written — not “the Peppol sweep”. If you do not have a code, say which screen is not doing its job and let the reply supply it;
- the cadence — how often, and whether a time of day matters (a consolidation sweep a few days before the 7th is a different request from “hourly”);
- the properties the job needs, where you know them: which company and branch, because several jobs read a company from their properties and abort the whole run if it is missing;
- and separately, your tenant code and what you expect to see once it runs, so the reply can tell you whether it did. The tenant code is not your company code and not your branch code — three different codes, and sending the wrong one costs a round trip. If you are not certain which is which, say so and name your company instead; the reply can look the tenant up.
An applet that is not in the Applet Store. Name the applet, the login or team that needs it, and what you are trying to do with it — a few applets have a registry row that is deliberately retired and a different applet is the answer, and that reply is faster than an install.
A credential, token or seeded row. Say which one, which company, and — for anything with a test and a live side, such as the LHDN intermediary configuration — which environment. Configuration put on the wrong environment looks exactly like configuration that was never done.
Repairing documents that have already been written. This is the one where detail decides whether it can be done at all:
- the document numbers, or an export of them — a list beats a description every time;
- what you expected to happen and what happened instead, in that order;
- when it was finalised, and whether anything downstream has already picked it up — reported to LHDN, matched on a bank reconciliation, included in a submitted return. A document that has been reported is not corrected, it is superseded, and that changes the answer;
- what you have already tried. Re-finalising, undoing to draft and voiding all leave their own traces, and unpicking them comes first.
What not to send
Do not paste a password, an access key or an API token. Nobody here needs one, and a key that reaches a ticket has to be revoked. Do not send a spreadsheet of live customer records when the document numbers would do.
If the answer is “ask your administrator”, we do not mean us
Some pages send you to your own administrator instead — the person in your organisation who holds owner or admin rights. That is a different route and a faster one: permissions, applet settings that hide a tab or a button, and per-user defaults are all changed inside your tenant, by someone who already has the rights to do it. If a page tells you to ask your administrator and does not tell you which screen they should open, that is a fault on the page — tell us and we will fix it.