Clef is our own early-access bookkeeping product for music businesses. Its public tour brings royalties, invoices, expenses, and a ledger into one workspace. This story follows the statement-import boundary in committed source and an illustrative connector preview, with a clear distinction between a proposal, a posted record, and money received.
Different records, different meanings.
The public tour starts with familiar fragments: royalty statements, session invoices, expenses, and projects. A royalty total belongs beside its tracks and source. An invoice belongs beside its customer and payment state. A bank deposit answers a different question again: what actually arrived?
Putting them in one workspace makes their relationships easier to inspect. It also creates a responsibility to name each number carefully. Recorded income is a statement about the books; it does not establish that the bank balance has been reconciled. A collaborator estimate does not establish that anyone has been paid.
The screenshot above is a browser capture of Clef’s public music section. The three tracks, distributor names, and CAD 5,600 total are labelled example data on the product itself. They show the proposed experience, not an artist’s actual earnings or a measured customer outcome.
The file needs a visible interpretation.
In the committed DistroKid parser we checked, the import reads a delimited statement and looks for earnings, dates, tracks, and stores. Invalid earnings, dates, or withholding values produce skipped-row records with the original row number and a reason. The preview response includes that information alongside totals and track/store summaries.
That distinction matters: a file can be readable while some of its rows are unusable. A useful review needs to explain both the proposed result and the input that did not contribute to it. We verified the parser and response contract; we did not establish that every skipped-row explanation appears in every current screen.
The parser also hashes the input text to recognise a previously committed file. That is a specific duplicate check. A reformatted export can have different text while describing the same underlying activity, so a file hash alone is not proof that two statements are economically distinct. We checked the DistroKid path; the public mention of other distributors is not a verification of every import format.
Previewing and posting have separate consequences.
The web import preview stores a staging record with a token and expiry. It has therefore changed application state, but it has not yet posted the proposed statement to the ledger. The onboarding screen asks for a separate action: “Confirm & Post to Ledger”.
The committed posting function checks the workspace and administrative role, locks the matching preview record, and rejects an invalid or expired preview. If the same preview was already committed, it returns the existing transaction rather than inserting another one. These are implementation decisions visible in source, not a production security audit.
Keeping the approved preview attached to the posting request gives a retry something concrete to recognise. It also avoids asking a user to approve one set of numbers and then silently calculating a different set during submission. We did not execute a live posting or verify which migrations are deployed.
A proposal can be checked without becoming a payment.
We separately exercised Clef’s connected royalty-preview tool with entirely invented inputs: CAD 1,000 gross income, CAD 100 in fees, and a 25% collaborator split. The response reported that it performed no writes. This connector preview is a separate interface from the web import’s staging record.
The proposed journal had CAD 900 debited to cash, CAD 100 debited to distribution fees, and CAD 1,000 credited to royalties. That proposal balanced for this example. It was not posted, and the cash label did not verify a bank deposit.
| Amount | Value | Meaning in this example |
|---|---|---|
| Gross royalties | $1,000.00 | Income before the supplied fee |
| Distribution fee | $100.00 | The supplied fee |
| Net amount | $900.00 | Gross less the fee |
| Collaborator estimate | $225.00 | 25% of the net amount |
| Artist share estimate | $675.00 | Net less the collaborator estimate |
The statement and the deposit still need connecting.
The illustrative split gives someone a number to review. It does not settle the collaborator’s entitlement, send a payment, or establish a real-world agreement. Those decisions need their own inputs and authority.
In the web statement path, committed source uses a distributor clearing account for the net receivable and a separate settlement function links a statement to a deposit record. That is a different treatment from the connector’s illustrative cash proposal. We describe the two interfaces separately because sharing the Clef name does not make their accounting paths identical.
The same care applies outside bookkeeping. A sent request, an accepted destination record, and a completed job are three different states. Good software lets a person find which one they have reached, inspect the supporting evidence, and decide what happens next.
What this story establishes.
Clef’s public site identifies the product as early access. We verified its illustrative tour, inspected committed import and posting source, and observed one synthetic preview response. We have not measured reduced bookkeeping time, validated every statement format, audited the deployed ledger, or demonstrated an end-to-end bank reconciliation.
The useful product lesson is concrete: retain the original, make the interpretation checkable, separate proposal from commitment, and give repeated requests a known result. Those boundaries deserve design attention before expanding the list of integrations or adding an AI summary.
A boundary worth carrying into your project.
A review screen needs a precise consequence. These questions apply to imports, administrative tools, and AI features that propose changes.
- The original
- Which file or source record explains the number, and can someone return to it?
- The proposal
- What has been calculated, what was skipped, and what still needs checking?
- The confirmation
- Who can approve, what will be written, and which version are they approving?
- The repeat request
- How does the system recognise work it has already completed?
See the product for yourself.
We checked the public product pages and the implementation behind the workflows on October 11, 2026. These links let you explore the public experience.