Accounting from the source
How to turn documents from LINE into a traceable work queue
Turn messages and files into tasks with event identity, company/period, owner, state, duplicate control and defined retention.
Teams often use LINE because sending a receipt photo is easy. The problem comes later when nobody knows who owns it, whether it was submitted twice or where to find it at month-end. The answer does not have to be banning chat; it is turning each intake event into tracked work.
This article uses the LINE Messaging API as a public implementation example. It does not claim that every Linda application uses the same bot integration in production.
Capture the message event and source content before interpretation
LINE sends webhook events when users send messages or files to an Official Account. Message events contain message IDs that can be used to retrieve image, video, audio or file content while that content remains available. An intake service should retain permitted event/message identity, sender, time and original evidence before OCR or classification.
LINE recommends verifying webhook signatures before processing because an endpoint can receive requests from outside LINE. This authenticates the delivery channel; it does not prove the accounting validity of the document itself.
Turn the document into a task instead of leaving it as a message
Create a task ID linked to the message ID and capture preliminary type, company, period, owner and due date. If the company is unknown, route the task to a clarification queue rather than guessing from group name or sender.
A reply can acknowledge the intake with a task number and missing context, for example “Document received as #DOC-1042; please identify the company.” This gives the sender evidence that the document entered the workflow and reduces uncertain resubmission.
Distinguish redelivery from genuinely different documents
Webhook delivery can repeat after failures, and users may also send the same image twice. Use event/message identity to prevent processing the same event repeatedly, while treating image fingerprints or metadata only as signals for possible duplicate review rather than automatic merge.
LINE documents webhook redelivery and does not promise a fixed number or interval. Downstream processing therefore needs idempotency from the intake boundary.
References: [1]
Workflow state should explain what is missing
An illustrative state model is Received → Needs Context → Ready for Review → Approved/Rejected → Exported/Posted → Reconciled, with actor and timestamp on transitions. When OCR cannot establish an amount, route to review rather than forwarding a guessed value.
An accounting-firm queue should be filterable by client, period, document type, owner and age so month-end review identifies missing work without reopening every chat.
Define source retention and access from the beginning
Chat files can contain personal or commercially sensitive data. Decide which system retains a copy, who may access it, how long it is retained and how deletion is handled. Do not assume the chat API is a permanent document archive.
LINE states that user-sent content is automatically deleted after a period and text cannot be fetched again through an API after webhook receipt. A downstream system that needs records later should store them under its own authorised retention controls.
References: [1]
A practical starting checklist
- Verify webhook signatures and retain event/message identity.
- Create a task with company, period, owner and state.
- Make event processing idempotent and review possible document duplicates.
- Use states that show missing context and next ownership.
- Define source-file access and retention.
Apply it to your business
LINE can remain a convenient intake channel. Operational value appears when each message becomes a traceable task with identity, ownership, evidence and explicit state.
References
- LINE. (n.d.). Receive messages (webhook). Retrieved October 1, 2026.
- LINE. (n.d.). Messaging API reference. Retrieved October 1, 2026.
Numbered references support the attributed statements. Scenarios and recommendations are Linda’s examples, not verified client outcomes.
This article provides process-design guidance and illustrative examples, not an accounting, tax or legal determination or certification of every software module. Apply it with regard to your business, permissions and actual system scope.