The customer's signature on waste handover documents, no paper involved

At a recycling facility, the moment a batch of waste comes in is also the moment most exposed to disputes. Who handed it over, what exactly, who confirmed it: if that information isn't on paper (or an electronic document) in the correct form, any later discussion with the customer or an ANPM inspection starts from a weak position.

VanaGreen already had e-signature capture at intake: the customer signs on a tablet or phone when handing over waste, just like the operator does. What was missing was the next, seemingly small step: the customer's signature never made it onto the printed document, Anexa 2 or Anexa 3 (the official Romanian waste-handover forms), even though the operator's signature was already there.

What changed

The templates for Anexa 2 and Anexa 3 (docs/document-templates-v1/anexa2 and anexa3) now use, in the shipper/customer's "Signature and stamp" cell, the same logic already used for the tenant's signature: if a saved signature image exists for that document, it's rendered directly into it.

The backend for this already existed: the client-signable-hook already listed Anexa 2 and Anexa 3 among the document types a customer can sign, and correctly refused rendering on outgoing documents (which have no associated intake collectionId). The only thing missing was the <img> tag in the template. The rest of the infrastructure was already there, built for a different use case.

This is a deliberately scoped change limited to intake: outgoing documents (handover to carrier/final recipient) don't have customer signature yet, because that flow doesn't have an equivalent on-screen capture moment.

Why it matters for a recycling operator

For someone running a collection point or sorting center, the intake document (Anexa 2/3) is the official proof that a batch of waste legally entered custody, with the identity and consent of whoever handed it over. Until now, that proof lived in two different places: the e-signature, stored digitally in the app, and the printed document, which only carried the operator's signature.

In practice, if someone later disputed the handover, saying "I never signed that" or "the document doesn't reflect what I handed over," the correct answer existed in the system, but wasn't visible on the paper the customer holds or shows during an inspection. Now the two sources converge: the printed document contains exactly what was captured electronically, with no manual step, no copying, no risk that someone forgets to attach the proof separately.

For an operator handling a high daily volume of intakes, the benefit is less about one isolated dispute and more about reducing friction at every routine inspection. An ANPM inspector or a partner requesting traceability documents no longer gets "the signature is in the app, let me show you on my phone." They get the complete document.

How the feature got there

As often happens, the visible feature was preceded by a few rounds of fixes to the signature capture itself, typical problems for any canvas- and touch-based interaction on mobile: a capture run that could get stuck with no way to cancel, a stroke path that didn't close correctly on pointercancel, and a case where the Content Security Policy (CSP) silently blocked converting the signature from a data: URL into an image blob.

Each of these bugs, on its own, was invisible to anyone not looking directly at the capture code. But any one of them, left unfixed, would have meant a signature that simply doesn't save, leaving the customer with the impression they'd signed when nothing had actually happened. Only once capture was stable did it make sense to wire it up to the printed document as well.

What's next

The natural extension is to cover the outgoing flow too, handover to the carrier or final recipient, with the same kind of capture and document rendering. It's not scheduled yet, but it's the logical next step once feedback from operators already using intake confirms it's worth extending.