Unit4 CODA Financials

CityScreen Deals can post approved invoices into Unit4 CODA Financials as accounting transactions, so that the ledger is written from the same invoice the sales side approved.

The exchange is one-way and outbound: invoices go to CODA, and CODA’s acceptance or rejection comes back as a status on the invoice.

What gets sent

CityScreen Deals sends invoices. Each approved invoice becomes a CODA input document made up of three kinds of line:

Analysis lines

One per billable item on the invoice, carrying the value and the analysis codes that tell CODA which part of the business the revenue belongs to.

Tax line

A single line for the tax total, derived from the analysis lines and the configured tax rate.

Trade debtor line

A single balancing line for the invoice total, coded to the customer.

Configuration

CityScreen enables CODA for your organization and records its connection details.

Connection details are held per organization and cover three things:

Authentication

An OAuth2 machine-to-machine credential — token endpoint, client ID and client secret — used to obtain a token for the Unit4 API.

Service endpoints

The addresses of the CODA authenticate, company and input web services.

Company and document defaults

The CODA company code to post into, and the document code the created transactions carry.

CityScreen sets up this configuration together with whoever administers your CODA installation.

What must exist first

The push reads CODA’s coding structure from directories in CityScreen Deals. Before the first invoice can be posted, the organization needs:

  • a document type that represents the CODA-bound invoice;

  • directories holding the CODA analysis levels, line types and invoice statuses.

What this page describes is the mechanism. The specific kinds — document types, fields, statuses — are defined for your organization; yours may differ. See the entity system.

The values inside those directories are your chart of accounts: analysis codes, client categories and divisions differ from one CODA installation to the next, and are set up to match yours.

See Directories for how reference data is maintained.

The flow

  1. An invoice document reaches the point where your process approves it.

  2. Deals builds the CODA input document from the invoice, expanding it into analysis, tax and trade-debtor lines and resolving each analysis code against the directories.

  3. The document is posted to CODA.

  4. CODA’s response moves the invoice’s CODA status — accepted or rejected.

The trigger is the approval itself: an invoice goes to CODA when the process approves it. If an invoice needs to go again, it goes through the same approval path.

Because the step sits inside a business process, where exactly it fires — and what happens on either side of it — is part of the process you model.

Statuses

The push writes two statuses.

The CODA invoice status tracks the document’s life on the CODA side: created, ready to send, approved for sending, then accepted or rejected by CODA.

The invoice status on the document itself records the outcome for the sales side — that the invoice was sent to CODA, or that the attempt failed.

An invoice that CODA rejected keeps the values it was sent with. Correcting it means fixing the invoice and letting the process approve it again.

When it fails

A failed push surfaces as an incident on the business process instance that ran it, carrying the error CODA returned.

To send the invoice again, retry the process instance.

See Troubleshooting Sync.

Related pages

  • Invoices — the invoice document and its line items

  • ClearTax / LHDN — e-invoicing, a separate outbound path for the same invoices

  • Directories — the reference data the push resolves against

  • Service Tasks — how a process reaches an integration