Payment Ledger Export

The Payment Ledger is an accounting export: a configuration your workspace sets up once that says exactly what leaves Itsy for your accounting system. One row per payment, cash in and out. Anyone can then pick a date range and download it as a plain CSV.

It lives under Reports > Accounting and is separate from the Payments report, which is for looking at payment activity on screen. That report is untouched -- its filters, saved views, and ZIP export all work exactly as before.

Itsy sends a feed; your accounting system keeps the book. Despite the name, this is a journal rather than a ledger: a chronological list of cash movements. It carries no running balances and nothing in it is marked reconciled. Itsy emits a feed into your accounting system's book of record; it does not hold one.

How it works

An admin sets the export up once. Everybody with access can then download it.

Your workspace has one Payment Ledger -- there is nothing to name and nothing to choose between. The page opens on the ledger itself: a date range at the top, the rows underneath, and the download button beside the range. The rows are generated by the same code as the file, so what you see is what you get.

There are two settings panels, behind the two buttons beside the download button: the gear for which payments the file contains, and the columns button for which columns it has. The chips next to the period summarise both -- click any chip to open the panel that owns it, at that setting.

The rows always show your saved settings. Changing something in a panel does not change them until you save, at which point the panel closes and the rows refresh.

Which payments are in the file

This is the part to read before you rely on the export. The rules are deliberate and some of them differ from the Payments report.

That last rule is the important divergence. The Payments report hides payments whose order was later cancelled, which is helpful noise reduction on screen. In an accounting file it would be a defect: a payment exported on Monday against an order cancelled on Tuesday would vanish from every later download with no reversing entry, and your books would permanently disagree with Itsy for no visible reason. So the export keeps them, and the Order Status column ships on by default -- a cancelled order's presence in the file should be visible rather than something you discover.

A cancellation that genuinely moved money back produces a refund row, which is how the reversal reaches your books.

Settings

Only admins can change the settings. Everyone else sees them read-only and can still download -- a standing instruction about what data leaves the system should not be edited casually.

These apply to the whole workspace and survive whoever set them up.

The period

Every period Itsy offers ends yesterday at the latest, because today is still open -- it keeps taking payments until midnight, so it belongs in tomorrow's file. Exporting a partial today either makes you do the day twice or leaves the late payments to be picked up by an overlapping range later.

To do a weekend one day at a time, pick One specific day and download Friday, then Saturday, then Sunday -- three files, one per day, which is what most accounting systems prefer.

Itsy does not track what you have already sent, so which period to pick is still yours to remember. The Payment Reference column below is what makes getting it wrong harmless.

The period lives in the page address, so a link to a specific one can be shared or bookmarked.

The date anchor

A download covers a period, and the anchor decides which date is compared against it.

• Created on (the default, and the one to keep) -- when the payment was entered into Itsy. A payment entered today and backdated to last week lands in today's file, and its Paid on column still says last week, so your accounting system posts it to the correct period. The range governs pickup; the row governs posting.
• Paid on -- when the money moved.
• Departure date -- when the order travels. Payments on orders with no departure date are left out entirely.

Anchoring on anything other than the created date reopens a real gap: a payment entered after its window has already been downloaded will never appear in any file, because nothing goes back to pick it up. Recording a payment with a past payment date is routine, so this matters. Itsy warns you when you change the anchor.

The payment reference

Overlapping ranges are expected -- a daily download of the last seven days sends each payment up to seven times. The Payment Reference column is each payment's own unique identifier, and it is what lets your accounting system recognise a row it has already imported and update it instead of adding it again.

It ships on by default and Itsy warns you if you remove it. Only remove it if you never import the same day twice.

Payment type code and name

Two columns describe the payment method, and they are not interchangeable:

• Payment Type Code is the accounting code set on the payment method. This is the identity your accounting system maps to an account.
• Payment Type is the name your team reads, included so the file makes sense without a lookup table. Renaming it in Itsy does not change what the code posts against.

Both ship on by default. A payment method with no code exports an empty cell, so fill in the codes on Data > Payment Methods before you rely on the export.

Available columns

The catalogue is deliberately wide so you can satisfy your accountant without waiting for a release. Columns marked default are selected when a new export is created.

Payment

Order

Client

Participant

The default selection, in order, is: Payment Type Code, Payment Type, Segment Code, Order Code, Paid On, Amount, Departure Date, Created On, Client, Client ID, Payment Reference, Origin, Order Status.

The file

Rows are ordered by payment date, so two downloads of the same range produce the same file.

A range with no payments produces a file with just the header row. That is intentional: a quiet day is a legitimate answer for an accounting feed, and an importer should accept it.

Common tasks

Setting up the export

1. Fill in the Accounting Code on each of your payment methods under Data > Payment Methods.
2. Navigate to Reports > Accounting.
3. Click Set up Payment Ledger. It starts with the default columns.
4. Open the columns panel and adjust which columns you get, and their order, to match what your accounting system imports. Click Save.
5. Open the gear panel to set the segments, the date anchor and the default period. Click Save.
6. Check the rows on screen. They are what the file contains.

Downloading the daily file

1. Navigate to Reports > Accounting.
2. The period is already set to your default -- yesterday, or the last few closed days. Check the rows look right.
3. Click the download button.

Catching up after a weekend

1. Click the period chip and choose One specific day, then pick Friday.
2. Download, then repeat for Saturday and Sunday.

Or choose The last few closed days and set it to 3 for a single file covering all three.

Checking a past period against your books

1. Click the period chip and choose A custom range, then set the period you want to verify.
2. Confirm the rows on screen look right -- they are the file.
3. Click the download button.

Known gaps

These are worth knowing before somebody asks why a figure does not match.

• A payment edited after its window has been downloaded is not re-sent. Correcting an amount does not change when the payment was created, so nothing brings it back into a later file. Your accounting system keeps the original figure until you correct it there.
• A payment deleted after being downloaded produces no reversing row. Nothing in a later file indicates it is gone.
• Anchoring on Paid on or Departure date can lose payments entirely, as described above.
• Itsy does not track what it has already sent. Selection is purely by period, so which one to pick is yours to remember, and downloading overlapping periods re-sends rows. This is why the payment reference matters.
• A day starts and ends by your computer's clock, compared against the time Itsy recorded in UTC. For an Icelandic workspace those agree; elsewhere a payment either side of midnight can land in the neighbouring day's file.
• There is no scheduling or automated delivery yet. Every file is downloaded by a person.

Who can do what

How it connects

• Payments report -- the on-screen view of payment activity, with filters and saved views. Unchanged by this feature, and it links across to the accounting export.
• Payment Methods -- where the accounting code on each payment method is set.
• Segments -- how an export is scoped to one brand.