Skip to main content

Important limitations

Read carefully before enabling automatic write-off for a customer — the process is new (beta) and has specific behaviors. New features will be added in upcoming versions.

API limits

Rate limit of 3 req/s and 120,000/day

It is 3 requests per second and 120,000 per day per Bling account — Koncili controls this on its own side. On overflow, the item waits and is automatically re-queued, never failing because of it.

1-day window per query

Each receivables query covers only 1 day — asking for a period longer than 1 year in a single query returns an error from Bling.

Sync start date is fixed

The sync start date (set at connection time) must be at most 1 year in the past and cannot be changed afterwards — it becomes read-only on edit.

There is no test environment (sandbox)

Bling has no sandbox — even in testing, Koncili talks to the production host.

When the write-off is blocked

Value divergence

If the receivable value in Bling does not match the value calculated by Koncili, the write-off is blocked (the item becomes FAILED) — it never writes off at the wrong value. The occurrence is recorded and can be seen in the Smart Report.

Installment ambiguity

When a sale has several installments and the value match becomes ambiguous, the item fails rather than risk writing off the wrong receivable (see Linking receivables).

Empty category is accepted

An empty category is accepted in practice, even though Bling documents the field as required — Koncili simply does not send the field when it is blank.

When the connection becomes invalid

There is no separate "expired" state

The four situations below collapse into an invalid credential, requiring a manual reconnection (the "Reconnect" button):

  • The refresh_token is rejected after ~30 days unused (the window slides: it renews on every successful refresh).
  • A reauthorization attempt fails.
  • A write-off is aborted by a 401 whose refresh also failed, or by a 403.
  • The credential is manually deactivated.

What hasn't been implemented yet

No proactive failure notification

There is only the binary "sent" icon (see Tracking and validation) — which does not distinguish success from failure.

Button does not re-enable after a failure

If the write-off fails, the "Send to ERP" button stays disabled indefinitely for that reconciliation — with no automatic reset. This feature will be added in the future.