Processor Reconciliation
The Partner Portal can show processor settlement health across your linked POS customers without exposing their bank account details.
Open Partner Reconciliation.
Who this guide is for
This guide is for approved Synalux resellers reviewing settlement health for customers who explicitly have reconciliation access enabled. It is a read-only support and portfolio workflow.
You can review what has been reported and whether it has been matched. You cannot:
What the report proves
Synalux follows each settlement through:
The three verification modes are equal first-class choices:
| Workspace mode | Evidence | GL destination |
|---|---|---|
| Bank feed | Cleared Plaid, Mercury, or imported bank deposit | Bank cash |
| Manual deposits | Cleared deposit recorded by the customer administrator | Bank cash |
| Processor only | Processor lifecycle reaches paid | Undeposited funds / cash in transit |
A processor batch marked closed is not reconciled. In bank modes, the customer
must fully allocate cleared deposit evidence. In processor-only mode, the batch
must reach paid and then reconcile automatically under the customer’s setting
or through an audited customer-administrator action.
The accounting sequence is:
``text
POS activity
→ Stripe or Dejavoo clearing account
→ normalized processor batch
→ bank/manual mode: cleared deposit allocation → bank cash journal
→ processor-only: paid evidence → cash-in-transit journal
`
Partial bank allocations remain open and do not create partial settlement journals.
The customer can select only a bank deposit from the same workspace and
currency as the processor batch. The database rejects a cross-workspace or
cross-currency allocation even if the displayed amounts are equal.
Before you expect a customer to appear
A Synalux platform administrator must:
or Detail report access;New reseller customers begin with None. Summary or Detail cannot be granted until an operating workspace is linked. Resellers cannot type or change workspace IDs.
Access levels
| Level | What you can see |
|---|---|
| None | Customer setup/link state only |
| Summary | Processor list, counts, reported net deposits, fees, open items, reconciled items, and exceptions |
| Detail | Summary plus individual processor batch drilldown |
Synalux platform administrators link the correct operating workspace and approve the access level. Resellers cannot enter or change workspace IDs.
Access can be reduced or revoked at any time. A revoked customer no longer contributes settlement totals. If the customer is linked to the wrong workspace, contact Synalux support; do not attempt to infer the correct workspace from internal identifiers.
Each grant, reduction, revocation, and workspace relink passes through the
Synalux platform-admin audit wrapper. Audit writes are best effort; a logging
failure is surfaced to operators but does not strand an administrator midway
through access recovery. Resellers cannot change these settings through the
Partner Portal.
What the portfolio looks like
The portfolio separates customers with Detail, Summary, and None access. Only a Detail row has an expandable batch list. Summary metrics also preserve the verification mix, so a portfolio can show both the reconciled total and how many were processor-verified.
Synalux reads every authorized result page before calculating the portfolio, so
large approved portfolios do not silently lose customers or batches at a fixed
row limit.
Information never shown
The reseller report does not include:
Customer administrators retain the bank-matching workflow in their Accounting module.
Reported net and fee totals stay separated by currency. Synalux never adds,
for example, USD cents to EUR cents and labels the result as one currency.
Continuity transparency
When a customer whose primary processor is Dejavoo has a station switched to the
backup processor, Synalux emits a record of it so the outage is visible to you
rather than only to the venue. This is separate from settlement reconciliation:
it reports continuity behaviour, not money movement.
Six event types are recorded:
| Event | Emitted when |
|---|---|
activated | an admin switches a station to the backup processor |
reverted | that station is switched back to the venue default |
transaction_succeeded | a card payment captures while the station is on the backup |
transaction_failed | a card capture on the backup is declined, or throws |
exception_quarantined | a payment taken on the backup is quarantined for review by the stored-and-forward sweep |
report_generated | a partner reconciliation report is produced |
Both halves of a capture are recorded: a decline and a thrown/timed-out capture
each emit transaction_failed, so the failure count on your dashboard reflects
what the venue actually experienced rather than only the successes.
What travels with an event. A fixed field list only: venue and workspaceidentifiers, the station, the processor moved from and to, amount in minor units,
currency, a reference id, and the operator's stated reason. Nothing else is
attached, and the reason text is scrubbed before it leaves — digit runs and email
addresses are redacted, so a gateway message like "declined for card 4242"
cannot carry a card fragment onto a partner dashboard. Card data, cardholder
names, and PAN fragments are never emitted.
Note the difference from Information never shown above: that section describes
the Partner Portal report, which does not display internal workspace ids.
Continuity events are a separate telemetry channel feeding a dashboard, and
they do carry venue and workspace ids as filter facets — that is how a dashboard
is scoped to one partner's merchants. Neither channel carries bank details,
Plaid data, or accounting journal ids.
Attribution is opt-in and explicit. Events are emitted only for venues thatcarry your partner tag. A venue without the tag emits nothing at all — there is
no default and no inference from the reseller hierarchy, so a merchant cannot
appear on the wrong partner's dashboard. Ask Synalux support to attribute a
venue to you; until that is set, the dashboard is correctly empty.
Failover itself is documented for the customer inincluding that refunds always return through whichever processor took the
original payment.
Daily reseller workflow
- processor;
- batch identifier;
- close date;
- reported net deposit;
- processing fee;
- status.
Do not describe a closed or paid processor batch as bank-reconciled. Processor status and bank proof are separate facts.
In bank modes, eligible evidence must be a cleared positive deposit with
unallocated value in the same workspace and currency. Plaid pending rows,
ignored rows, and fully allocated rows cannot be used.
For a processor-only customer, do not ask for a bank match. Read the
Processor-verified label and remember that the customer’s journal debit
remains in undeposited funds/cash in transit.
Reading statuses
| Status | Meaning | Reseller action |
|---|---|---|
| Awaiting deposit | Batch totals are present; no complete bank allocation exists | Watch the expected timing; escalate after normal processor/bank delay |
| Partially matched | Part of the expected deposit was allocated | Record the remaining open amount and ask the customer to review split/combined deposits |
| Reconciled | The batch completed its recorded verification mode and the settlement journal posted once | Check the verification source before describing it as bank-verified |
| Processor-verified | A processor-only workspace reconciled a paid batch to cash in transit | No bank-match request; monitor processor exceptions and later cash-transfer operations |
| Exception | The batch or expected processor source needs customer or Synalux review | Escalate with the non-sensitive batch facts listed below |
A previously reconciled batch can return to Exception when the processor
later reports the payout as failed or reversed. This does not erase its original
verification label or journal. It creates an explicit accounting-review signal;
escalate it rather than describing the prior deposit or processor verification
as final.
Provider-specific expectations
Stripe
Stripe payout events are retained as evidence. The report still depends on normalized payout totals and the workspace’s selected verification mode.
Dejavoo
Dejavoo is mock/manual-only until production credentials and batch access are configured. A Dejavoo batch shown in a non-production demonstration uses the same accounting and reporting workflow, but it is not evidence that a production Dejavoo connection is live.
Do not instruct a customer to point a production Dejavoo terminal or webhook at an unconfigured environment.
Common questions
Why is a paid processor batch still awaiting verification?
In bank-feed or manual mode, Paid is still only the processor’s claim and
reconciliation waits for cleared bank-side evidence. In processor-only mode,
the customer may have disabled automatic reconciliation and must use the
audited verify action.
Why does a reconciled batch say Processor-verified?
The customer explicitly chose processor-only verification. Synalux posted the
debit to undeposited funds/cash in transit, not bank cash. Historical labels do
not change if the customer later switches modes.
Why does the portfolio total differ from one bank deposit?
One deposit can fund multiple batches, and one batch can be split across multiple deposits. Fees, refunds, chargebacks, tips, and adjustments also affect the net.
Why are there multiple reported-net totals?
The reseller has activity in more than one currency. Totals remain separated
because adding unlike currencies would produce a false portfolio amount.
Why can I see totals but not a Details button?
The customer has Summary access. Batch drilldown requires Detail.
Why is a customer listed as setup pending?
The reseller-customer row is not linked to an operating workspace. A Synalux platform administrator must verify and create the link.
Can I reconcile the deposit for the customer?
No. Only the customer workspace administrator sees Plaid candidates and saves allocations.
Troubleshooting
| Symptom | Check | Escalate when |
|---|---|---|
| Customer absent | Confirm the customer relationship is active and access is not None | Platform admin confirms a valid grant but the customer still does not appear |
| No batches | Confirm the customer has processor activity and an imported normalized report | Provider evidence exists but no report appears after the expected import window |
| Awaiting verification too long | Check the workspace mode, expected date, grace period, and payout lifecycle | The mode-specific grace period has passed |
| Partial match | Ask the customer to review split or combined deposits | Remaining amount cannot be explained |
| Processor-only exception | Check for negative net, failed/reversed payout, stuck pre-paid lifecycle, or missing expected daily batch | Immediately; do not ask for a bank match |
| Bank/manual exception | Record processor, batch ID, close date, and amount | Customer accounting review is required |
Escalation checklist
Before opening a support ticket, record:
Do not request or attach full bank account numbers.
Also do not send Plaid transaction descriptions, bank transaction IDs, merchant account IDs, workspace IDs, processor credentials, webhook secrets, or screenshots containing those values.
What support needs from you
A useful escalation says:
Northstar Cafe · Dejavoo · batch batch_123` · closed July 22 · reported net $776.00 · partially matched.
It does not include bank credentials, full account numbers, raw processor payloads, or secret configuration values.