Cardinal

Accounting

Books an accountant can sign

Most small-property systems have a balance field. Cardinal has a book of account: every money event is an immutable posting, corrections are reversals, and the server decides what the books say.

Part 9 of 108 sections7 questions answered
The Cardinal tax and ledger screen: filed monthly periods, gross charges, net tax, the accountant summary with revenue by category and net tax split into GST and QST, and payment reconciliation

Tax and ledger on the demo property. Every figure here is a query against the postings, not a reconstruction from a total.

The ledger

Append-only, enforced by the database

A posted entry is permanent

Postings live in a ledger table with database triggers that physically refuse a modification. A mistake is corrected by posting a reversal, never by editing history.

The server computes the money, not the browser

Charge amounts are re-derived server-side from the stay and the property's saved tax configuration, then compared to what was submitted. A posting whose numbers do not reproduce is refused.

Every posting must foot

Base plus tax equals amount. Tax components must sum to the tax total. Signs are enforced by type. One bad posting rejects the whole batch, so nothing partial is ever written.

Two people, the same payment, one posting

Posting runs inside a single database transaction that locks that one folio while it writes. Six simultaneous submissions of the same $50 payment produce one posting. That is measured in a test, not assumed.

Authorized corrections

A manager-authorized reversal writes the authorization into the ledger itself: who, what role, why, when. The server refuses a reversal that arrives without it.

A refund and a correction are two different instruments

Money genuinely owed back to a guest is an ordinary thing to do at the desk and needs no manager. Undoing an entry that should never have been made is error correction, and that one carries the authorization, the reason and a limit of one reversal per transaction. Treating them as one action either puts a manager password in front of a routine refund or lets anyone rewrite the books, and both of those are the wrong trade.

Voids and discounts post as credit lines

The original charge is never overwritten. The net is reached through the full set of postings, so the trail shows what happened and when.

You cannot edit a posted transaction in Cardinal. Neither can we. That is the point.

Tax

Per-component, per-night, in your timezone

Tax is stored as components, not a percentage

GST, QST, PST, HST and lodging tax are separate columns on every posting, so the remittance report is a query rather than a reconstruction.

Rounded per night, then summed

Room tax is rounded per night and summed, so the ledger foots to the printed invoice to the cent. A four night stay at $169 comes to $800.92 on the quote, the folio, the ledger and the export.

A void reverses the split, not just the total

Cancelling a charge negates each tax component separately, mirroring the way the charge was posted, and a discounted line credits net of the discount. A void that only negates the total leaves the GST and QST counted as collected, which foots on the folio and overstates the return you file.

Dated in the property's timezone

Not the server's and not the staff member's browser. A payment taken at 9pm on June 30 lands in June's return, not July's.

Deferred revenue is tracked

Cash collected for a stay that has not happened is a liability, not revenue, and the report says so, split between fully unearned future stays and pro-rata unearned mid-stay guests.

Closing the month

Period close, and a sweep before you read anything

A closed period is locked

A posting dated into a closed period is not rejected and not lost. It is redated into the current period with the original date preserved in its metadata, which is what an accountant expects.

A check for missing lines before every report

Before any accounting report is read or exported, the system sweeps the whole property and compares every reservation, activity and sale against what the ledger actually holds. Missing lines are posted.

Every exception surfaces in plain language

Anything the sweep would have to guess at is put in front of you in plain language rather than silently healed. A reconciliation that quietly fixes itself is one you can only hope is right.

Retention

Daily backups, with each month's first backup retained permanently, toward CRA's six year records requirement.

When something does not agree

The flag comes with the correction attached, and still waits for you

Any system can tell you a folio does not reconcile. What usually follows is a support ticket and somebody with database access. Here the same screen that raises it works out the entries that would settle it, shows you what they do, and then stops and waits, because posting them is your decision and not the software's.

It shows the consequence before the button
Four figures, each with a before and an after: what the guest's folio nets, what sits on the charge side, what is marked as billed to the company, and what the company actually owes. You read where every book lands before anything is written.
A correction is a pair, not a void
Money closed off a guest lives in two books, so clearing one of them moves the imbalance rather than settling it. The real case that taught this: voiding a $46 charge on its own left the folio at $46 in credit, which reads as a refund owed to a guest who was owed nothing.
It would rather propose nothing than guess
If it cannot land every book in agreement it says so and offers no button. Most findings resolve to exactly that, which is the reason the ones it does propose are worth reading. Where a company has already paid for a stay that never happened, it says that the money is real, that a credit note is the right instrument, and that settling the refund is a decision above the panel.
It names the cause in your own language
Company over-billed. Billed to nobody. Money left behind. Cannot be decided. Four plain descriptions of what has actually happened, in place of a variance figure you would have to reverse-engineer.
Nothing posts without a reason on it
The correcting entries carry who authorized them and why, into the same append-only ledger as everything else, so the fix is as readable a year later as the mistake was.
One rule, read by both the panel and the nightly check
The overnight sweep and this screen import the same test. A folio cannot be flagged by one and quietly cleared by the other, which is the ordinary way two checks on the same books drift apart.

Exports

What your accountant receives

  • Detailed transaction CSV with tax split by component
  • An accountant summary
  • A GST and QST remittance report: collected minus adjustments equals net owing
  • A payment reconciliation
  • A monthly archive keeping all four reports for every completed month
  • Configurable GL codes, mapped at export rather than frozen into the record

We describe mechanisms, not outcomes. Cardinal is not a certification and does not guarantee a compliance result. Your accountant decides what these records mean for your filing.

Questions

Asked and answered

Can I edit a transaction after it is posted?

No, and that is deliberate. Posted transactions are immutable at the database level. To correct one you post a reversal, which requires a manager authorization and a stated reason, and both are written into the ledger. This is what makes the books auditable.

What if my front desk makes a mistake?

Every mistake is fixable. Voids, discounts, refunds and manager-authorized reversals all exist. The difference is that fixing it leaves a trail instead of erasing the evidence.

Can I close a month so nobody changes filed numbers?

Yes. Close the period and it is locked. A transaction dated into a closed period is not rejected and is not lost. It is redated into the current period, with its original date kept on the record.

What does my accountant get?

A detailed transaction export with tax split by component, an accountant summary, a GST/QST remittance report, a payment reconciliation, and a monthly archive that keeps all four for every completed month. GL codes are configurable and mapped at export.

Do you have a night audit?

No, and there is nothing here for one to do. A night audit exists in legacy systems because the books are only correct after a batch process rolls the day. In Cardinal every transaction posts as it happens and the ledger is always current. Instead of a nightly close there is an automatic sweep that resolves no-shows and overdue check-outs, and a completeness reconciliation that runs before you read any report.

What happens if two people take the same payment at the same time?

One payment is recorded. Posting runs in a single database transaction that locks that one folio while it writes, and every payment carries a one-time key, so the same submission arriving twice is recognised as the same payment rather than counted twice. Six simultaneous submissions of the same $50 produce one posting. This is a test we run, not an assumption.

How do I know the numbers are right?

Roughly forty dedicated automated test suites cover the money paths: tax arithmetic, folio math, ledger reconciliation, refunds, rates, packages, concurrency. Several thousand assertions run in multiple timezones on every change. Beyond that, the system reconciles the entire property against the ledger before any report is exported and flags anything it cannot verify.

Every question, in one place →

See it running

Watch a day run before you talk to anyone.

Six real screens from a working property, in the order the day happens. Open it now and go at your own pace.