PROJECT 02 • DATA PIPELINE • IN DEVELOPMENT
Receipt to Home Database
A self-hosted household system that turns receipts into structured purchase history for spending analysis, price comparison and inventory tracking.
PROJET 02 • PIPELINE DE DONNÉES • EN DÉVELOPPEMENT
Du reçu à la base de données du foyer
Un système auto-hébergé qui transforme les reçus en historique structuré des achats pour analyser les dépenses, comparer les prix et suivre l’inventaire du foyer.
Why I am building it
I wanted a better view of household spending and a practical inventory tracker for everyday items. It is easy to walk into a store, forget what is already at home, spend more time than necessary and still leave without what we actually needed. Bank tools can show where money went at a high level, but they rarely explain exactly what was purchased, why the basket cost what it did or what the same item cost previously.
In a way, receipts tell a story. I want to uncover that story so my wife and I can make better household decisions with a budget-friendly, self-hosted system that either of us can use.
Pourquoi je le construis
Je voulais avoir une meilleure vue des dépenses du foyer et un suivi pratique de l’inventaire des articles du quotidien. Il est facile d’arriver au magasin, d’oublier ce qu’on a déjà à la maison, d’y passer trop de temps et de repartir sans ce dont on avait réellement besoin. Les outils bancaires montrent généralement où l’argent est allé à un niveau global, mais ils expliquent rarement ce qui a été acheté, pourquoi le panier a coûté ce montant ou combien le même article coûtait auparavant.
D’une certaine façon, les reçus racontent une histoire. Je veux rendre cette histoire exploitable pour aider mon épouse et moi à prendre de meilleures décisions avec une solution auto-hébergée, abordable et utilisable par les deux membres du foyer.
Questions I want the data to answer
Collecting data is not the goal by itself. The useful part is being able to answer practical household questions with history instead of guesses.
Questions auxquelles je veux répondre
Accumuler des données n’est pas une fin en soi. L’objectif est de répondre à des questions concrètes du foyer à partir de l’historique plutôt que d’intuitions.
Is Costco actually worth it?
L’abonnement Costco vaut-il vraiment la peine?
Compare membership-driven shopping against actual household purchase history.
Comparer les achats liés à l’abonnement avec l’historique réel du foyer.
Did buying in bulk save money?
Acheter en vrac a-t-il réellement permis d’économiser?
Separate lower unit cost from simply buying more than necessary.
Distinguer un meilleur prix unitaire du simple fait d’acheter plus que nécessaire.
Was the specialty-store trip worth it?
Le détour vers un magasin spécialisé en valait-il la peine?
Compare item prices while considering the extra trip cost and shopping pattern.
Comparer les prix des articles en tenant compte du coût du déplacement supplémentaire et des habitudes d’achat.
Where is this item usually cheaper?
Dans quel magasin cet article est-il généralement moins cher?
Build product price history across stores and over time.
Construire un historique de prix par produit, par magasin et dans le temps.
What do we already have at home?
Qu’avons-nous déjà à la maison?
Use inventory status to reduce forgotten items and duplicate purchases.
Utiliser l’état de l’inventaire pour réduire les oublis et les achats en double.
Where is household spending going?
Où vont les dépenses du foyer?
Review spending by store, category, product and household attribution.
Analyser les dépenses par magasin, catégorie, produit et attribution au sein du foyer.
System architecture
The design separates document capture, automation, local AI extraction, structured storage, inventory and analytics. PostgreSQL is the authoritative structured source of truth; Paperless-ngx remains the document archive, n8n orchestrates the workflow, Grocy is the inventory side and Metabase is intended for analytical views.
Architecture du système
La conception sépare la capture des documents, l’automatisation, l’extraction locale par IA, le stockage structuré, l’inventaire et l’analyse. PostgreSQL demeure la source structurée de référence; Paperless-ngx conserve les documents, n8n orchestre le flux, Grocy gère l’inventaire et Metabase est destiné aux vues analytiques.
On smaller screens, scroll the diagram horizontally to keep the labels readable.
Sur un petit écran, faites défiler le schéma horizontalement afin de conserver les libellés lisibles.
Data quality before analytics
Receipt extraction is only the beginning. The workflow needs to preserve raw information, clean and validate extracted values, normalize products and aliases, resolve household attribution, detect duplicate processing and keep unresolved cases in review instead of silently pushing uncertain data downstream.
La qualité des données avant l’analyse
L’extraction d’un reçu n’est que le début. Le flux doit préserver les données brutes, nettoyer et valider les valeurs extraites, normaliser les produits et alias, résoudre l’attribution au foyer, détecter les doubles traitements et conserver les cas non résolus en révision plutôt que d’envoyer silencieusement des données incertaines vers les étapes suivantes.
Raw
Preserve original OCR/extraction output for traceability.
Conserver la sortie OCR/extraction originale pour la traçabilité.
Staged
Parse and clean values into a consistent structure.
Parser et nettoyer les valeurs dans une structure cohérente.
Normalized
Validate, standardize, map and categorize records.
Valider, standardiser, mapper et catégoriser les enregistrements.
Analytics
Expose curated views for spending, price history and operational monitoring.
Exposer des vues préparées pour les dépenses, l’historique des prix et le suivi opérationnel.
Database & workflow design
Conception de la base et des flux
Receipts & line items
Separate receipt-level data from each purchased line item while retaining source-document references.
Séparer les données du reçu de chaque article acheté tout en conservant la référence au document source.
Canonical products & aliases
Map store-specific descriptions to reusable canonical products without duplicating the product catalogue.
Mapper les descriptions propres aux magasins vers des produits canoniques réutilisables sans dupliquer le catalogue.
Review & idempotency
Keep low-confidence or unresolved cases reviewable and prevent duplicate workflow actions.
Conserver les cas incertains ou non résolus pour révision et empêcher les actions de flux en double.
Household attribution
Support household member, shared-household and guest/external attribution without losing unresolved splits.
Prendre en charge l’attribution à un membre du foyer, au foyer partagé ou à un invité/externe sans perdre les répartitions non résolues.
Inventory outbox
Separate database completion from external inventory writes so synchronization can be retried safely.
Séparer la finalisation en base des écritures vers l’inventaire externe afin de pouvoir relancer la synchronisation de façon sûre.
Analytics views
Curated PostgreSQL views support spending, price history, review queues and processing health.
Des vues PostgreSQL préparées soutiennent l’analyse des dépenses, l’historique de prix, les files de révision et l’état du traitement.
Visuals to add as the data grows
These spaces are intentionally reserved for real dashboards and charts once enough validated household history is available. No spending totals or accuracy metrics are fabricated.
Visualisations à ajouter avec l’accumulation des données
Ces espaces sont volontairement réservés aux vrais tableaux de bord et graphiques lorsqu’un historique validé suffisant sera disponible. Aucun total de dépenses ni taux de précision n’est inventé.