Skip to main content
The Light integration posts the invoices Alguna issues — and the credit notes and customers behind them — into your Light company entity, so Light stays the accounting system of record while Alguna runs quoting, subscriptions, usage, and collections. Invoices created in the dashboard and through the API sync the same way; see How Alguna works for the objects involved.

​
What is synced

Alguna does not post payments into Light. Collections stay in Alguna, and the Light invoice carries the receivable.
Light models accounts receivable credits as customer credits. Light’s own credit notes resource is the accounts payable, vendor-side record, and Alguna never touches it.

​
Connecting Light

Connecting takes two steps, and nothing syncs until both are done.
1

Enter your API key

Go to Integrations and click Connect on the Light tile, then paste your Light API key.
2

Pick a company entity

Alguna loads the company entities your key can reach. Choose the one to sync into.
One Alguna integration maps to one Light company entity. If you connect again with a fresh API key and pick an entity that’s already connected, Alguna merges the new key into the existing integration rather than creating a second one — which is how you rotate a key.

​
Product mapping

Light requires a catalogue product on every invoice line, so each Alguna product needs a SKU, and your Light catalogue needs a product whose name matches that SKU exactly. Alguna resolves each line by looking up its product’s SKU in your catalogue. Two things stop an invoice before anything is written to Light, both surfacing as sync issues naming the line:
  • An Alguna product with no SKU
  • A SKU with no matching product in the Light catalogue
Lines that carry no Alguna product at all — contract discounts, spend-threshold adjustments, ad-hoc lines — ride a single shared placeholder product called Alguna line item, which Alguna creates once per Light company the first time a line needs it. The invoice still displays the real line description. This placeholder is the only product Alguna ever writes into your catalogue, and it deliberately carries no default tax or ledger account, so posting it somewhere specific is your call.

​
Custom properties

If your Light company requires custom property groups on invoice lines, Alguna fills the text ones with the line’s SKU description. A required single-select group is filled with its sales option when it has one. A required group Alguna can’t fill — a select group with no sales option, or any other input type — refuses the sync with a message naming the group. Make the group optional in Light, or change it to a text property, then retry.

​
Revenue release

Alguna attaches a revenue release to invoice and credit lines only when the integration holds a revenue release template ID. Light exposes no endpoint to list templates, so the ID is copied from Light and stored on the integration; ask your Alguna contact to set it. Release dates follow the line’s service period. A period no longer than the legal entity’s deferred revenue threshold collapses to its first day, a longer period keeps its actual range, and a line with no period uses the document date. See Revenue recognition.

​
Invoice updates

Alguna keeps the Light invoice in step while Light still allows edits. Once Light locks the record, Alguna stops rather than forcing a change, and raises a sync issue telling you to edit it in Light. That happens when the Light invoice is paid, has payments recorded against it, or has been reversed. Opening an invoice is asynchronous in Light. Alguna waits briefly for the invoice to finish opening, and if it’s still in progress the edit is retried on the next sync rather than acting on a half-opened record.

​
Credit notes

A credit note becomes a Light customer credit, created and posted, then applied to the credited invoice. Because Light offers no lookup by external reference, Alguna scans your existing customer credits before creating one and adopts a match rather than writing a duplicate, verifying the amount and currency first so a drifted earlier attempt is never posted. Applying the credit needs the Light invoice to have enough remaining balance to absorb it. Alguna refuses, with a message naming both amounts, when the balance falls short — Light may carry payments Alguna doesn’t know about, so the shortfall is real rather than a rounding artifact.

​
Refunds

When the invoice is already paid in Alguna, the credit note is a refund. Alguna creates and posts the customer credit and then leaves it open, without touching the Light invoice. Light has no refund primitive, and applying a credit to a paid invoice would misstate cash that has already gone back to your customer. Leaving the credit open is the closest honest record, and an operator settles it in Light.

​
Sync failures

Problems detected before calling Light (a product with no SKU, a SKU missing from the catalogue, a company entity that was never chosen) and errors returned by Light open a sync issue under Settings → Connections → Sync issues, with the reason and the affected record. Fix the mapping or the record and retry from there. See External sync for issue statuses and categories. Retries are safe. Alguna adopts the record it already wrote instead of creating a second one, so re-syncing a failed invoice or credit note never doubles it up.