Author: admin

  • Closing the books in hours, not days: what a combined ledger changes

    Closing the books in hours, not days: what a combined ledger changes

    Ask a finance team where month-end actually goes, and the answer is almost never “posting journals.” Posting is quick. What consumes the days is everything that happens between systems: exporting payables, importing them somewhere else, chasing the difference between a subledger total and the control account, and re-checking figures that were already correct when they were first entered.

    Where the time really goes

    In a conventional setup, accounts payable, accounts receivable and the general ledger are three separate stores of truth. Every transaction is recorded once in a subledger, then again — in summary — in the GL. That second recording is the problem. It introduces a gap, and the gap has to be reconciled before anyone can trust a report.

    Most closes are therefore spent proving that two systems agree about something that only happened once.

    What a combined ledger changes

    A combined ledger removes the second recording. AP, AR and the GL are one product sharing one ledger, so a supplier invoice does not post to a payables system and then flow into the general ledger later. It posts into the ledger, immediately, as a journal like any other.

    The consequence is simple: there is no subledger-to-GL reconciliation, because there is no subledger sitting apart from the GL.

    The practical difference

    • No export and re-import. Nothing moves between systems, so nothing can be lost, duplicated or mistyped in transit.
    • Reports are current by definition. Standard reports read the ledger directly. A journal posted at 11am appears in the trial balance at 11am.
    • One audit trail. Every posting carries its origin, its approver and its date in a single chain, rather than being reconstructed across three systems.
    • Fewer control accounts to babysit. Control accounts stop being a reconciliation exercise and become what they were meant to be — a summary view.

    What it does not fix

    A combined ledger is not a substitute for good process discipline. It will not chase a supplier for a missing invoice, decide your accrual policy, or tell you that a cost has been coded to the wrong department. Bank reconciliation still has to happen, because that is a genuine comparison between two independent records — your ledger and the bank’s.

    What it removes is the artificial reconciliation: the work created by your own systems rather than by the business.

    A realistic expectation

    Teams moving to a combined ledger usually find the close compresses in two stages. The first is immediate — the subledger reconciliation simply disappears. The second takes a cycle or two, as people stop building spreadsheets to bridge gaps that no longer exist.

    The honest measure of success is not the number of hours saved in the first month. It is whether, by the third close, anyone still asks whether the ledger and the subledger agree.

  • Flexible journal types, explained: sequences, printing, and auto-reversal

    Flexible journal types, explained: sequences, printing, and auto-reversal

    “Flexible journal type” sounds like a configuration detail. In practice it is one of the few settings that determines whether your accounting system adapts to your entity, or your entity adapts to the software.

    What a journal type is

    A journal type is a category of posting with its own rules — accruals, provisions, payroll, recurring adjustments, revaluations. Most systems ship with a fixed list. A flexible system lets you define your own, and attach behaviour to each one.

    Sequences

    Each journal type carries its own numbering sequence. This matters more than it first appears. When accruals run on their own sequence, an auditor asking to see every accrual in a period gets a contiguous, self-evident range rather than a filtered extract of a single global sequence.

    It also makes gaps meaningful. A missing number in a dedicated sequence is a question worth asking. A missing number in a shared sequence usually means nothing at all.

    Document printing

    Different journal types need different documents. A payment voucher, a receipt, a journal slip for internal sign-off — each has its own layout and its own audience. Tying the document format to the journal type means the right paperwork is produced automatically, rather than assembled by hand after the fact.

    Auto-reversal

    This is the setting that quietly saves the most time. Accruals and provisions exist to be reversed next period. If reversal is manual, it is a recurring task that someone has to remember, and occasionally does not.

    With auto-reversal set on the journal type, the reversing entry is generated for the following period at the moment the original is posted. The reversal is visible, dated and auditable — it is not a hidden system behaviour, but it also is not something a person has to schedule.

    A worked example

    Suppose you accrue a quarterly audit fee. You define a journal type called Accruals, give it its own sequence, attach an internal journal slip for the approver, and set auto-reversal to the next period. From then on, posting the accrual produces the accrual, the reversal, the document and the audit trail in one action.

    Why fixed journal types cause drift

    When a system will not let you define a journal type, teams improvise. They overload a generic “adjustment” type, then encode the real meaning in the description field. Six months later, finding every provision means searching free text — and the answer is only as reliable as the least careful person who typed it.

    Flexible journal types are, in the end, a way of keeping meaning in structured fields where it can be queried, rather than in prose where it cannot.

  • What invoice OCR actually automates, and what it should not

    What invoice OCR actually automates, and what it should not

    Invoice OCR is often sold as the end of data entry. It is not, and the gap between that promise and what the technology actually does is where most disappointing implementations live.

    What OCR is genuinely good at

    Optical character recognition, paired with a bit of layout intelligence, is reliable at reading recurring documents from known suppliers. When the same utility company sends the same invoice layout every month, the system learns where the invoice number, date, net amount and tax sit, and extracts them accurately.

    For a payables team processing a few hundred such invoices a month, that is a real reduction in keystrokes.

    What it is not good at

    • First-time suppliers. There is no learned layout, so extraction is a guess.
    • Judgement. OCR can read a line item. It cannot decide which cost centre it belongs to, or whether the charge was authorised.
    • Poor scans. A photographed invoice at an angle, in bad light, will produce plausible-looking wrong numbers — which are more dangerous than obvious failures.
    • Tax treatment. Reading a tax amount is not the same as knowing whether it is recoverable.

    The word that matters: drafts

    The right mental model is that OCR drafts a journal. It does not post one. The draft arrives with the fields it is confident about already filled, and a human confirms, corrects and codes it.

    This distinction is not timidity about automation. It is what keeps the audit trail meaningful. A posting that no person ever looked at is a posting no person can explain.

    Where approval fits

    OCR and approval workflow solve different problems and should not be collapsed into one. Extraction reduces typing. Approval establishes authority. An invoice can be perfectly extracted and still be one nobody agreed to pay.

    In a sound setup the sequence is: the document is read, a draft journal is created, a person reviews and codes it, an approver signs off, and only then does anything post to the ledger.

    Measuring it honestly

    The useful metric is not “percentage of invoices automated.” It is the proportion of drafted invoices that a reviewer accepts without correction, tracked by supplier. That number tells you where the technology is genuinely earning its place, and where someone is quietly re-typing everything the system got wrong.

    Automate the typing. Keep the judgement.

  • Ten analysis dimensions: designing cuts finance will actually use

    Ten analysis dimensions: designing cuts finance will actually use

    Analysis dimensions are cheap to create and expensive to maintain. Most systems will happily let you define ten of them per function. The discipline is deciding which ones earn their place.

    A dimension is a question you will ask repeatedly

    The test is simple: will someone ask for this cut every month, in a meeting, and act on the answer? Cost centre passes. Project usually passes. “Campaign sub-type” almost never does — it gets created for one initiative and then quietly rots.

    Every dimension you add is a field someone has to populate correctly on every relevant posting, forever. The cost is not the setup. It is the ongoing accuracy.

    Design for the report you need, not the data you have

    Start from the management pack. List the reports the board actually reads, and work backwards to the minimum set of dimensions that produce them. If a dimension does not appear in any report, it is speculative.

    Keep values shallow and stable

    • Shallow. A dimension with forty values that nobody can remember is a dimension that will be miscoded. Aim for a list a person can hold in their head.
    • Stable. Renaming or merging values later makes historical comparison painful. Choose names that survive a reorganisation.
    • Mutually exclusive. If two values overlap, coders will guess, and the guesses will not be consistent.

    Make the right value the easy value

    Defaults do more for data quality than training does. If a department almost always codes to the same cost centre, default it. People correct defaults; they rarely fill blanks thoughtfully.

    Review annually, retire honestly

    Once a year, list every dimension and every report that uses it. Anything with no consumer should be retired rather than carried forward out of politeness. A smaller set of trustworthy dimensions beats a larger set that people quietly work around in spreadsheets.

  • Batch AP payments without the manual bank upload

    Batch AP payments without the manual bank upload

    Paying suppliers usually involves two disconnected acts: recording the payment in the ledger, and separately telling the bank to move the money. Most of the risk in payables lives in the gap between them.

    The manual pattern and where it breaks

    The familiar routine is to select invoices for payment, post the payment entries, then build a file or key the payments into the banking portal by hand. Two lists of the same payments now exist, maintained by hand, and they can disagree — a supplier paid twice, an amount transposed, a payment recorded but never sent.

    Booking and file generation as one action

    The alternative is to treat payment selection as the single source. You choose the invoices to settle; the system posts the payment entries and produces the bank file from that same selection. There is no second list, so there is nothing to reconcile between them.

    What this changes in practice

    • Totals always agree. The file total is the posted total, because both derive from the same set of records.
    • Bank details come from the supplier master. No re-keying of account numbers at the moment of payment, which is where fraud and typos concentrate.
    • The audit trail is continuous. Invoice, approval, payment entry and bank file are linked rather than assembled afterwards.
    • Partial payments stay honest. Settling part of an invoice updates the open item correctly instead of relying on a memo.

    What still needs a human

    Automation here removes transcription, not authority. Someone must still approve the payment run, and dual authorisation at the bank remains a sensible control. The point is that the person approving is looking at the same figures that will actually leave the account.

    Before you switch

    Confirm your bank’s file format and test with a small run. Clean the supplier master first — bank details, currency, payment terms. A payment file is only as good as the data it is built from.

  • Journal approval that prevents reversals instead of recording them

    Journal approval that prevents reversals instead of recording them

    Every finance team has a story about a journal that should never have posted. The usual response is a reversal, a note, and a promise to be more careful. A better response is a step that makes the posting impossible in the first place.

    Reversals record problems; approvals prevent them

    A reversal is an honest correction, and there is nothing wrong with it. But a ledger full of reversals is a ledger that is documenting its own rework. Each one costs a posting, an explanation, and a small amount of trust in the numbers between the error and the fix.

    What a configurable approver step actually costs

    The objection is always speed. In practice, a well-scoped approval adds seconds to routine work, because most journals do not need approval at all. The value comes from scoping it narrowly.

    Scope by risk, not by habit

    • Approve journals above a value threshold.
    • Approve anything touching equity, tax or intercompany accounts.
    • Approve manual journals; leave system-generated postings alone.
    • Approve entries posted to a closed or closing period.

    Approving everything is how approval workflows get switched off within a quarter.

    Make review meaningful

    An approver who sees only a total is a rubber stamp. The review screen should show the full entry, the supporting document, and who prepared it. Segregation matters too: the preparer should not be able to approve their own work, including by proxy.

    The measure that matters

    Track the number of reversals per period before and after. If reversals fall and the close does not lengthen, the control is working. If reversals fall because people stopped posting anything at all until the last day, the scope is too wide — narrow it.

  • Moving off spreadsheets: a clean opening-balance import

    Moving off spreadsheets: a clean opening-balance import

    The most common reason a migration stalls is a belief that the old books must be perfect before anything can move. They do not need to be perfect. They need to be explained.

    What you are actually migrating

    Two things: opening balances by account, and open items — the unpaid supplier invoices and uncollected customer invoices that make up your payables and receivables balances. Historical transaction detail is usually better left in the old system, archived and readable.

    Attempting to bring ten years of line-level history across is where migrations lose months for very little benefit.

    Reconcile once, properly

    Pick a cutover date, ideally the start of a period. Produce a trial balance at that date and agree it. Then list open items and confirm that their totals equal the payables and receivables control balances. If they do not, the difference is a real problem in the old books and you have just found it — fix it before the import, not after.

    Use the template

    Opening balances and open items come in through an Excel import template. Prepare, review and import. Because the import is a file, it is reviewable before it posts and repeatable if something needs correcting.

    Run a parallel close

    Do one period in both systems. It feels wasteful and it is the single best predictor of a calm switchover. You are checking that the two closes agree, and more importantly that your team can produce the close in the new system without help.

    A realistic sequence

    • Agree the cutover date and freeze the chart of accounts.
    • Reconcile the trial balance and open items at that date.
    • Import opening balances, then open items.
    • Verify control accounts tie back.
    • Close one period in parallel.
    • Switch, and keep the old system readable for reference.

    Migration is mostly bookkeeping discipline, not technology. The import is the easy part.

Let our system handle the ledger while you focus on the business. AP, AR, and GL in one product — built by Strategic Asia since 2015.

+65 8833 0800simon@sbgsea.comSingapore · Malaysia · Thailand · Indonesia
Copyright © 2026 AOC Accounting | All right reserved.Back to top ↗