Correcting and resending

Two actions let you act on days that have already been exported. They solve different problems:

	Recompute	Re-export
Use it when	the figures were wrong, usually because an accounting rule was wrong	the figures were right, but the receiving system did not get them or lost them
What it does	recalculates the days from the stored transactions with today's rules	recalculates nothing
What is sent	one new journal per day that changed, holding only the difference, with a new journal ID	every journal already sent for those days, again, unchanged, with the same journal IDs
If nothing changed	nothing is sent	the same journals are sent anyway
API endpoint	POST /tenants/{tenantId}/general-ledger-replay	POST /tenants/{tenantId}/general-ledger-re-export

🛑 Re-export does not correct anything. It resends exactly what was sent before, wrong figures included. After fixing a rule, recompute.

When a rule was wrong

Say an accounting rule sent non-food items to the food sales account, and the store's day has already been exported and posted in your accounting system. Here is what happens when you fix it.

1. Journal #41 has already been sent. It posted 800 to 3000 Food, but 300 of that was non-food.
2. You correct the rule so that category 12 goes to 3010 Non-food, and recompute 23 September. General Ledger recalculates every transaction of that day with the corrected rule. The day should have been 500 on 3000 and 300 on 3010.
3. Journal #44 is published with only the difference: debit 300 on 3000, credit 300 on 3010. VAT and the card account did not change, so they are not in it.

Your accounting system posts journal #44 like any other journal. Journal #41 is not withdrawn or changed, and does not need to be reversed by hand:

journal #41 + journal #44 = the corrected day

So yes, a recompute produces a delta, calculated the same way as for a late transaction: what the day is now, minus everything already sent for it. The rules for reading a delta are in Journals and deltas. The two you will see most after a correction:

• An amount moving off an account appears on that account's opposite side, here the debit of 300 on 3000. It is never a negative credit.
• An account that is no longer used at all is reversed in full. Had all 800 belonged on 3010, journal #44 would contain debit 800 on 3000 and credit 800 on 3010.

Step by step

1. Correct the rule in CCC. See Accounting rules.

2. Wait ten minutes. A rule change reaches General Ledger within about ten minutes, and a recompute started earlier may still use the old rule and find nothing to correct.

3. Recompute the affected business dates, for one business unit or for all of them, from the General Ledger tool or the API:

   curl --request POST "https://general-ledger-api.retailsvc.com/api/v1/tenants/${TENANT_ID}/general-ledger-replay" \
     --header 'Content-Type: application/json' \
     --header "Authorization: Bearer ${API_TOKEN}" \
     --data '{
       "businessUnitId": "EU002",
       "businessDate": { "from": "2026-09-01", "to": "2026-09-23" }
     }'

4. Receive one correction journal per business date that changed, published straight away. Dates where the new rule makes no difference get no journal.

5. Check the response for blocked days (see below).

⚠ Today is recalculated, but not sent yet. If the range includes the store's current business day, that day is recalculated with the new rules and exported by the normal schedule once the day has ended.

Re-export

Use re-export when the figures are right but have to be delivered again: a new accounting system is being connected, or the receiving side lost messages.

curl --request POST "https://general-ledger-api.retailsvc.com/api/v1/tenants/${TENANT_ID}/general-ledger-re-export" \
  --header 'Content-Type: application/json' \
  --header "Authorization: Bearer ${API_TOKEN}" \
  --data '{
    "businessUnitId": "EU002",
    "businessDate": { "from": "2026-09-01", "to": "2026-09-23" }
  }'

Every journal already sent for those days is sent again, straight away: the first journal and every delta, each as a separate message with its original journal ID and amounts. They are marked as a re-export (see Receiving the journals).

🛑 A receiving system that already has a journal must skip it. Posting a re-exported journal a second time doubles that day. Recognise a journal by business unit and journalId.

Limits that apply to both

Limit	Detail
Date range	from to to, both inclusive, and at most 90 days apart per request. Split longer periods into several requests.
Business units	Name one businessUnitId, or leave it out to include every business unit that has exported journals in that range. A business unit that has never exported in the range must be named.
One request at a time	While an earlier recompute or re-export is still being processed, and for three minutes after the last request from your tenant, a new request is refused with 409 There are pending requests, please try again later. Wait and send it again.
Permissions	gle.general-ledger.replay for recompute, gle.general-ledger.re-export for re-export.

The request is accepted with 202, and the work continues in the background. The response lists, per business unit, any blocked dates in the range.

Blocked days

A store's business day is blocked when one of its transactions could not be balanced, usually because an amount had no matching rule (see When a transaction cannot be balanced). A blocked day gets no new journal, from the schedule or from a recompute, so an unbalanced journal never reaches your accounts. Journals sent before the day became blocked stay valid, and re-export still resends them.

Recompute and re-export both report blocked days in their response:

[
  { "businessUnitId": "EU002", "blockedBusinessDates": ["2026-09-12"], "correlationId": "…" }
]

To release a blocked day:

1. Fix the rules so every amount has an account. A DEFAULT rule in each kind prevents most cases.
2. Contact Extenda support to have the transactions that could not be balanced processed again. Recompute alone cannot release the day, because the transaction that was held back was never posted.

Once the transaction balances, the day is exported as normal.