Campfire: bank feeds and journal entries
A contract-level look at bank-feed ingestion, journal construction and the distinction between a recorded bank event and a posted accounting result.
- Bank event
- Accounting decision
- Journal and lines
Investigation question
Does importing a bank transaction mean creating a journal entry? The public API exposes both workflows, so this investigation asks which state each operation represents and where an integration should verify accounting consequences.
Observed
Campfire publishes separate bank-feed and journal-entry workflows. The journal guide begins with retrieving references needed to construct a journal for the intended entity, then supplying its accounting lines. The bank-feed surface represents incoming banking information. The documented bank-sync option to skip journal creation means ingestion and posting are not interchangeable concepts. These interfaces give an operator two distinct things to inspect: the imported event and the journal that expresses an accounting decision. The presence of one does not, by itself, prove that the other exists or contains the intended accounts and amounts.
Inferred
A useful interpretation is that ingestion answers “what did the external feed report?” while a journal answers “how is this event represented in the accounts?” Keeping those questions separate makes duplicate diagnosis clearer. A retry of an import and a second accounting entry are different failure modes. The separation also changes status language. “Imported” is a defensible statement about a feed record. “Posted” needs evidence from the accounting object. Reporting every accepted feed item as posted would hide the very distinction the API allows.
Unknown & limitations
No live feed was connected and no journal was posted for this article. The analysis does not establish how every tenant configures automatic posting, matching or closed-period controls. It also does not prove transaction isolation, event ordering or webhook delivery guarantees. Consult the endpoint contract and observe the resulting records before treating a transport response as final accounting state.
Domain & data models
Conceptual model: bank account → incoming bank event → review or matching decision → journal and accounting lines. This is a client-facing reasoning model, not a claim that Campfire implements these stages as four independent services. Entity and account references are part of the journal context and should remain visible in integration records.
Workflows & state machines
Illustrative scenario: a bank feed reports a 100-unit deposit. A client using the documented skip-journal mode should verify the imported event separately from any later accounting entry. A reviewer may then associate it with an existing transaction or create an appropriate journal. The example amount describes a test case, not an accounting recommendation. A bounded test plan would record the selected feed mode, inspect the resulting banking record, then look for a journal using the documented relationship or reference. A second test would deliberately use the explicit journal workflow and verify entity, line references and returned status. Those observations establish behavior more reliably than counting successful HTTP requests.