Six parts of bookkeeping foundations and what automation changes

Almost nothing about the method has changed in a very long time. What changes, constantly, is how transactions arrive, who sends them, and how much of the typing somebody else has already done.

A useful way to read any change is to ask which old checks it retires and which it makes more important.

What to take away

The six numbered parts below are the ones automation does not touch.
What automation changes is the shape of the errors. Omissions and typos fall; plausible mis-coding at scale rises.

The six parts

Double entry.Every transaction has two sides that must agree.
Evidence.An entry is only as good as the document behind it.
Event date.The event date decides the period, not the payment date.
Reconciliation to an outside record.Books are proved by agreement with an outside record.
Locked period.A closed period stops changing.
Recording is evidence, deciding is rules.

The two halves of the job

Does not move	Moves every few years
Every transaction has two sides that must agree	How the transaction reaches the ledger
An entry is only as good as the document behind it	Where that document is stored and how it is captured
The event date decides the period, not the payment date	How many separate parties send you data about the same event
Books are proved by agreement with an outside record	What form that outside record arrives in
A closed period stops changing	How filings and submissions are made
Recording is evidence, deciding is rules	Who is physically doing the entry

Read a new feature against the left column. If it claims to remove something from it, the claim is wrong. If it changes something in the right column, work out what that does to your checks.

Entry is cheap now, and that moved the error

Typing was once most of the work, so most errors were errors of typing and omission: the invoice nobody entered, the transposed figure, the month left half done. Those errors are loud. A missing entry shows up as an unreconciled difference, and a transposition usually fails to balance against something.

Old errors versus new errors

Old errors (loud)

Cause: Typing and omission
Example: Missing invoice entry
Example: Transposed figure
Example: Month left half done
How found: Fails to balance

New errors (quiet)

Cause: Rules and integrations
Example: Mis-coding at scale
Example: Duplication from two feeds
Example: Confident mismatching
How found: Comparison to expectations

Automated capture and suggested coding remove a lot of that work, and with it a lot of those errors. What replaces them is quieter.

Mis-coding at scale.A human miscodes one courier charge. A rule miscodes every courier charge for eight months, and the resulting report looks smooth and consistent, which is exactly why nobody questions it.
Duplication from two directions.The same purchase arrives once through the bank feed and once through a card integration or a captured receipt. Both are plausible, both have a date and an amount, and nothing about either looks wrong on its own.
Confident mismatching.A payment is matched automatically to an invoice of the same value that it does not actually pay. The bank reconciles, the customer's balance does not, and the aging report quietly becomes fiction.

None of these announce themselves in a trial balance. They are found by comparison: this month against the last two, this account against what you expected, this supplier's ledger against the statement they sent. The specific errors and their symptoms are set out in the errors that damage a small set of books.

A suggestion is a pattern match, not a decision

Coding suggestions are trained on what you did before. That has one consequence worth stating plainly: a mistake you made last year comes back wearing the authority of a system recommendation, and it comes back on every similar transaction.

Two habits handle it. Review the rules themselves, not just the entries, once or twice a year, and delete any you cannot justify out loud. When you correct a coding error, ask whether the rule that produced it is still running.

The same applies to anything that posts without a person looking. Automatic posting is reasonable for high volume, low value, unambiguous items. It is a poor fit for anything where the right answer depends on a contract, a delivery date or a judgment, which is most of the interesting transactions.

More parties, more versions of the same event

A single sale can now generate records from four sources: your own invoice, a payment processor's settlement report, the bank line for the net deposit, and a marketplace's statement. Each is true and none of them is the transaction.

The skill this asks for is decomposition: taking one settlement figure apart into the gross amount the customer paid, the fee deducted, any tax collected, and any refund netted off inside the same payout. A business that records the deposit as a sale loses its fee visibility and understates its revenue in the same stroke.

Practically, that means reconciling to the processor's own report rather than to the bank alone, every period, and treating the payout as a net figure until proven otherwise.

Where filing and invoicing are moving

Watch several kinds of change here without acting on rumour. Submissions are moving from forms to structured data sent directly from software. Invoices are moving from documents to structured messages exchanged between systems. Identifiers are being required on transactions that previously carried none.

Whether any of that applies to you, and by when, is set by the authority in your own jurisdiction and by your entity type. Do not adopt a date, a threshold, or a format from a guide written for somewhere else.

Check at the source, starting with the public guidance on paying business taxes, then your own authority. In the United States, that means the IRS and your state tax authority. Write down what you found and when you found it, and set a reminder to check again.

What is worth doing regardless of the answer is making sure your records could support it. Keep counterparty details consistent, show tax separately rather than buried in a gross figure, and store documents that can be found from the entry.

That is most of what the federal guidance on what records a business keeps asks for anyway. Those steps cost nothing if no requirement ever arrives and save a scramble if one does. Which of these are yours to decide and which belong upward is covered in the piece on sorting bookkeeping questions by who answers them.

What the shift makes more valuable

Exception review over data entry.The measure of a good month becomes how few items needed a human and how quickly those closed, not how many were keyed.
Written definitions.When a machine proposes the coding, the only thing that makes the proposal checkable is a written statement of what belongs where.
Reconciliation to outside records.More automatic matching means more ways to be internally consistent and wrong. Outside agreement is the only test that still bites.
Locking periods.With entries flowing in continuously from several feeds, a period that is not locked will keep changing after you have reported on it.

The system requirements that follow from all of this are set out in the guide to choosing accounting software, and the method they support is unchanged in the bookkeeping foundations overview.

Common questions

Does automation mean I need less bookkeeping knowledge?

The opposite, in one narrow sense. Less of the work is typing and more of it is judging whether a proposal is right, and you cannot judge a proposal you do not understand.

Should I turn on automatic posting?

For repetitive, low value, unambiguous transactions, yes, with a monthly review of what it posted. For anything driven by a contract or a delivery date, no.

How often should I revisit my coding rules?

Twice a year, and always when a coding error is found.

Is any of this a reason to change systems?

Rarely on its own. Migration costs a period of unreliable comparatives and the loss of any convention that was not written down. Change when the current system cannot do something you actually need, not because a feature list is longer.

What should I check before believing a new integration?

Run it in parallel for one full period and reconcile both ways. Look specifically for duplicates and for automatic matches to the wrong item, because those are the two failures an integration produces that a balance check will not reveal.